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About This Manual 


This manual describes the Remote Installation Services (RIS) and Dataless 
Management Services (DMS) environments and utilities maintained on a 
Compaq Tru64 UNIX operating system. 


RIS lets you install software kits across a network from a centrally 
administered server instead of using locally mounted media. 


DMS lets client systems share the /usr file system on a centrally 
administered server over a network while still maintaining their own 
root (/) and /var file systems that reside on the DMS server. 


Audience 


This manual is intended for anyone using RIS or DMS, especially 
those system administrators responsible for maintaining RIS and DMS 
environments on your LAN. 


When you are using this manual, the following conditions apply: 


Your hardware is working properly. 
You have read the owner’s manuals supplied with your hardware. 


You know the location and function of the controls and indicators on 
your hardware. 


You understand how to load and unload the installation media and any 
disks needed during the installation. 


You know how to use the operating system software. 


New and Changed Features 


The following changes have been made to this manual since the last version: 


Revised instructions for determining CD-ROM devices to include both 
older and newer versions of the operating system, added instructions 
for locating physical drives, and relocated the information to the 
introduction (Section 1.3) 


Added information about hardware product kits in RIS areas (Section 4.4, 
Section 6.2) 


Expanded procedures to modify (Section 6.4) and remove RIS clients 
(Section 6.5) 
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¢ Added information about cluster members and cluster aliases to the 
procedure to add RIS clients (Section 6.2) 


e Added additional RIS troubleshooting information (Section 8.4.1) 

e Added additional DMS troubleshooting information (Chapter 13) 

¢ Moved DMS information about hardware releases to an appendix 
(Appendix D) 

Previous versions of this manual are available on the World Wide Web at 

the following location: 


http://www.unix.digital.com/faqs/publications/pub_page/pubs_page.html 


Organization 


This manual is organized as follows: 


Chapter 1 Introduces the concept of servers and clients, explaining 
what they are and how they work together. It also describes 
the basic architecture of the server/client environment. 


Chapter 2 Describes the relationship between the RIS 
server and RIS cients. 


Chapter 3 Lists the formats in which distribution media are available 
and describes the preliminary setup procedures for RIS. 


Chapter 4 Describes the procedure for setting up a RIS server, 
including installing and updating software. 


Chapter 5 Describes networking-related files and daemons used 
by the remote installation services (ris) utility and the 
process a client goes through to boot over the network. 


Chapter 6 Describes processes and procedures for maintaining 
and managing a RIS system, including adding, 
deleting, and modifying clients. 


Chapter 7 Describes how to manage profile sets to support Full 
Installation and Installation Cloning. 
Chapter 8 Provides information on troubleshooting RIS 
dient problems. 
Chapter 9 Introduces DMS and the dataless manage- 
ment utility (dmu). 
Chapter 10 Describes how to prepare a server system for DMS. 
Chapter 11 Describes the steps necessary to configure a DMS server 


including how to install software into a DMS environment. 


Chapter 12 Describes how to use the dmu utility to add, modify, 
remove, and list DMS clients, and how to list or 
delete a DMS environment. 


x About This Manual 


Chapter 13 Provides information on troubleshooting DMS 
client problems. 


Appendix A Contains a worksheet to use when you install RIS. 


Appendix B Contains worksheets to calculate space require 
ments on DMS servers and clients, and a DMS 
client setup worksheet. 


Appendix C Describes the utilupdate utility, used to update the 
the ris and dmu utilities on a server that is running 
an older version of the operating system. 


Appendix D Describes how to install a hardware update release intoa 


DMS area servingan older version of the operating system. 


Related Documentation 


You should have the following documentation available: 
¢ Thehardware documentation for your system 

¢ Redease Notes 

¢ Reference Pages Sections 8 and 1m 

¢« Systen Administration 

e Installation Guide 

¢ Installation Guide — Advanced Topics 

* Documentation Overview 


Tru64 UNIX documentation is available on the World Wide Web at the 
following location: 


http://www.unix.digital.com/faqs/publications/pub_page/pubs_page.html 


Icons on Tru64 UNIX Printed Books 


The printed version of the Tru64 UNIX documentation uses letter icons on 


the spines of the books to help specific audiences quickly find the books that 
meet their needs. (You can order the printed documentation from Compaq.) 


The following list describes this convention: 


Books for general users 
Books for system and network administrators 
Books for programmers 


Books for device driver writers 


DuoUDNN QA 


Books for reference page users 
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Some books in the documentation help meet the needs of several audiences. 
For example, the information in some system books is also used by 
programmers. Keep this in mind when searching for information on specific 
topics. 


The Documentation Overview provides information on all of the books in 
the Tru64 UNIX documentation set. 


Reader’s Comments 


xii 


Compaq welcomes any comments and suggestions you have on this and 
other Tru64 UNIX manuals. 

You can send your comments in the following ways: 

¢ Fax: 603-884-0120 Attn: UBPG Publications, ZK 03-3/Y 32 

e Internet electronic mail: readers comment@zk3.dec.com 


A Reader’s Comment form is located on your system in the following 
location: 


/usr/doc/readers_comment.txt 
« Mail: 


Compaq Computer Corporation 
UBPG Publications Manager 
ZK O3-3/Y 32 

110 Spit Brook Road 

Nashua, NH 03062-2698 


A Reader’s Comment form is located in the back of each printed manual. 
The form is postage paid if you mail it in the United States. 


Please include the following information along with your comments: 


¢ The full title of the book and the order number. (The order number is 
printed on the title page of this book and on its back cover.) 


e« The section numbers and page numbers of the information on which 
you are commenting. 


¢ Theversion of Tru64 UNIX that you are using. 
e If known, the type of processor that is running the Tru64 UNIX software. 


The Tru64 UNIX Publications group cannot respond to system problems 

or technical support inquiries. Please address technical questions to your 
local system vendor or to the appropriate Compaq technical support office. 
Information provided with the software media explains how to send problem 
reports to Compaq. 
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Conventions 


The following conventions are used in this manual: 


2 
6 


$ A percent sign represents the C shell system prompt. 
A dollar sign represents the system prompt for the 
Bourne, Korn, and POSIX shells. 


# A number sign represents the superuser prompt. 


% cat Boldface type in interactive examples indicates 
typed user input. 


file Italic (Slanted) type indicates variable values, 
placeholders, and function argument names. 


{3 In syntax definitions, brackets indicate items that 
are optional and braces indicate items that are 
required. Vertical bars separating items inside 
brackets or braces indicate that you choose one item 
from among those listed. 


cat(1) A cross-reference to a reference page includes 
the appropriate section number in parentheses. 
For example, cat(1) indicates that you can find 
information on the cat command in Section 1 of 
the reference pages. 


Return In an example, a key name enclosed in a box 
indicates that you press that key. 


Ctrl/x This symbol indicates that you hold down the 
first named key while pressing the key or mouse 
button that follows the slash. In examples, this 
key combination is enclosed in a box (for example, 
Ctrl/C} ). 
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Introduction to Sharing Software 


This chapter introduces software sharing and the components that make up 
a software sharing environment. This chapter includes the following topics: 


Software sharing concepts, components, and benefits (Section 1.1) 
Describing the software sharing environment (Section 1.2) 
Identifying your CD-ROM drive's device name (Section 1.3) 


1.1 Overview 


A server iS a computer system that provides another computer system with 
required or useful information or resources. The system that uses the 
information or resources from the server is called a client. A given server 
can serve one or many clients. Computers in a network can share disk space, 
lists of names, software kits, processing services, and other entities. 


For sharing software using Remote Installation Services (RIS) and Dataless 
Management Services (DMS), the server supplies software, software kits, 
and disk space for clients to use. 


The RIS and DMS services let you share software in the following ways: 


RIS sets up a system where one or more installable software kits are 
stored for installation across a local area network (LAN). With RIS, one 
computer, the RIS server, stores the kit in a special area (called the RIS 
area) on its disk. Other computers, called RIS clients, can install the 
software onto their own disks by accessing it across the network instead 
of from locally mounted distribution media (such as CD-ROM). 


DMS sets up a system in which you can save disk space by sharing the 
actual operating system software between computers. Without DMS, 
each computer has a copy of its operating system software on its own 
disk. With DMS, one computer, acting as a DMS server, stores the 
software in a special area (called the DMS area) on its disk. Other 
computers, called DMS clients, run by accessing the software across the 
local area network (LAN) instead of from their local disks. 


Caution 


DMS is not supported in a clusters environment. 
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TheRIS and DMS utilities share architectural similarities; the primary 
differences are in the contents of their respective server disk areas. 


The following list illustrates some of the benefits of sharing software: 


e« You can reduce your software and hardware costs by sharing software 
between computers. 


e« You are not limited to sharing one piece of software; you can share 
virtually all of your operating system software. 


e When you share software with RIS, you have a central location for all 
the software to install on your system and can install the same software 
simultaneously on several clients. 


« When you share software with DMS, several of the computers in your 
local area network (LAN) use a single copy of a given piece of software. 
This reduces the need for multiple copies of the same software, reduces 
the disk space required for software storage, and allows central 
administration of software resources. 


1.2 Understanding the Software Sharing Environment 


1-2 


The following components make up the environment for software sharing: 
A server 


The server’s system administrator prepares the server for RIS or DMS 
by creating the RIS or DMS areas on the server and ensuring that 
the server is connected toa LAN. A single server can serve both RIS 
and DMS clients, however a client cannot be registered to both RIS 
and DMS. 


A distribution device on the server 


For most servers, the distribution device is a CD-ROM drive or a 
software distribution copied directly to magnetic disk. You transfer 
or link the software subsets for one or more specific products and 
architectures from the distribution media to the RIS or DMS areas on 
the server. Registered clients can then access the software. 


A local area network (LAN) 


You must set up the server and all client processors as hosts on the LAN 
(using Ethernet, FDDI, or Token Ring for RIS and Ethernet or FDDI for 
DMS). Clients use the LAN to access the server’s RIS and DMS areas. 


Clients 


RIS clients are systems that can run the operating system for which the 
server provides kits. RIS clients must also be capable of booting over 
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Ethernet or FDDI using the BooTP and TFTP protocols to install the 
base operating system from a server. Layered products can be installed 
after the client’s operating system is running with the SysMan Menu. 


DMS clients must be capable of booting over Ethernet or FDDI 
using the BOoTP and TFTP protocols. Most Alpha workstations and 
servers have this capability, but some data center servers cannot be 
configured as DMS clients. Consult your system's user guide and 
related documentation to determine whether it supports BooTP and 
TFTP over Ethernet or FDDI. 


Note 


You cannot use RIS or DMS toinstall software on DEC 2000 
series or DEC 7000 series servers. 


1.3 Identifying a CD-ROM Drive Device Name 


There are many circumstances when you need to specify your CD-ROM 
drive's device name and you do not know the unit number of the CD-ROM 
drive. How you identify this unit number depends on whether your system 
is running a version of the operating system that uses traditional device 
naming conventions or newer device naming conventions. 


Use one of the following procedures to determine your CD-ROM drive's unit 
number: 


If you are using an older version of the operating system that uses 
traditional device naming conventions (/dev/rrzNc), use the file 
command, specifying the raw device, as shown in the following example: 


# file /dev/rrz*c 
/dev/rrzic: char special 
/dev/rrz2c: char special 


( SCSI #0 RZ25 disk #8 (SCSI ID #1) 

( 
/dev/rrz3c: char special (8/3074 

( 

( 


SCSI #0 RZ25 disk #16 (SCSI ID #2) 
SCSI #0 RZ25 disk #24 (SCSI ID #3) 
SCSI #0 RRD43 disk #32 (SCSI ID #4) 
8/17410) SCSI #1 RZ57 disk #72 (SCSI ID #1) 


/dev/rrz4c: char special 
/dev/rrz9c: char special 


# 


In this example, the CD-ROM device corresponds to the RRD device 
RRD43, and the CD-ROM drive's unit number is 4. The raw device name 
is /dev/rrz4c. 


To mount the device, insert the CD-ROM into the drive and use a 
mount command, specifying the character special device, similar to the 
following: 


# mount -rd /dev/rz4c /mnt 


This example uses a CD-ROM drive that is unit 4 and specifies /mnt 
as the mount point. 
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If you are using a later version of the operating system that uses newer 
device naming conventions (/dev/disk/cdromNc), use the 1s command 
as shown in the following example: 

# 1s -1 /dev/disk/cdrom* 


brw------- 1 root system 19, 69 Nov 18 06:11 /dev/disk/cdrom0a 
brw------- 1 root system 19, 71 Nov 18 06:11 /dev/disk/cdrom0c 


The CD-ROM drive's unit number is 0, and in the character special 
device name in this example is /dev/disk/cdrom0c. Raw devices have 
the same name but reside in the /dev/rdisk directory. 


To mount the device, insert the CD-ROM into the drive and use a mount 
command similar to the following: 


# mount -rd /dev/disk/cdrom0c /mnt 


This example uses a CD-ROM drive that is unit 0 and specifies /mnt 
as the mount point. 


If you have multiple CD-ROM drives and are not sure which drive 
corresponds to which device name, use the hwmgr command to flash 
the light on the drive. 


For example, if you want to determine which CD-ROM drive corresponds 
to /dev/disk/cdrom0c and you have two CD-ROM drives, place 
CD-ROMs in both drives and enter the following command: 


# hwmgr -flash light -dsf /dev/disk/cdrom0c 


You see the light on cdromoc blink for 30 seconds. 


Refer to the hwmgr(8) reference page for additional information about 
this utility. 
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Remote Installation Services 


This chapter introduces Remote Installation Services (RIS) and the ris 
utility, and explains the relationship between RIS servers and clients. The 
following topics are included: 


Understanding RIS concepts and the benefits of using RIS (Section 2.1) 
Starting RIS (Section 2.2) 

Introducing RIS areas and product environments (Section 2.3) 
Understanding RIS client characteristics (Section 2.4) 

Registering RIS clients (Section 2.5) 

Identifying a client’s hardware network address (Section 2.6) 


2.1 Overview 


Remote Installation Services (RIS) uses the ris utility to set up a central 
computer system (a server) to service multiple computer systems (clients) on 
a local area network (a LAN) with required software. 


With RIS, the server has a disk area set aside as the RIS area. The RIS 
area contains copies of software kits that are available for installation on to 
registered clients. Figure 2-1 shows how the RIS system works. 
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Figure 2-1: RIS Server and Client 
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The server maintains information in the RIS areas about what software 
kits clients can access. Kits are organized so that RIS can serve different 
versions of a software product to multiple hardware platforms and operating 
systems. The server’s RIS area uses the Network File System (NFS) to 
provide read-only access to RIS clients. 


Beyond verifying RIS clients’ identities and managing their kit load 
requests, the RIS server does not interact directly with the clients. You do 
not have to set aside a system as a dedicated RIS server; you can use the 
same system to support local timesharing users. 


A RIS client uses the set1d utility toinstall software kits from the RIS 
server instead of from local distribution media. 


The benefits and advantages of RIS include the following: 


¢ Installation and setup of servers and clients are done by scripts, thereby 
simplifying the server system administrator’s task. Maintenance of the 
server's disk areas is similarly straightforward. The system interfaceis 
the same regardless of system type. 


¢« Because RIS supports different hardware platforms and different 
software versions, it is adaptable to a wide variety of client systems 
and requirements. Servers running a given version of an operating 
system can serve clients running the same version or an earlier version 
of the operating system. In addition, if the ris utility on the server is 
updated to the current version with the utilupdate utility available 
on distribution media, RIS servers running an earlier version of the 
operating system can make later versions of the operating system 
available to RIS clients. 
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¢« RIS uses a single set of kit files for all clients having the same 
architecture. 


e You can perform a cloned installation on a RIS client, letting you 
duplicate a similar system installation or configuration. Refer to the 
Installation Guide — Advanced Topics for information about installation 
cloning and configuration cloning. 


2.2 Starting RIS 


You always should run the ris utility as superuser. To start the ris utility, 
enter the following command: 


# /usr/sbin/ris 
When RIS starts up, it checks the status of the RIS areas. 


If RIS can access all the products it was able to access the last time RIS was 
started, the ris utility displays the following message: 


Checking accessibility of RIS areas... done 


If RIS cannot access all the products it was able to access previously, it 
displays the following message: 


No Products Available in /var/adm/ris/ris0O.alpha 


Delete RIS environment? [y]: 


This may occur because the source for this RIS environment is no longer 
mounted, and can be corrected by remounting the source. If the source is no 
longer available, you may delete this RIS environment. If you remount the 
source, you must restart RIS so that the environment is available. 


If you try to start RIS without superuser privileges, the following message 
may be displayed: 
Checking accessibility of RIS areas... 


No permission to write /usr/var/adm/ris/ris0.alpha/ProdNames 
done 


Correct this problem by logging in as root or using the su command to gain 
superuser privileges before you start RIS. 


2.3 RIS Areas and Product Environments 


In addition to the server’s normal disk area, an area is reserved to hold RIS 
software kits. This RIS area contains one or more product environments. 
Each product environment contains one or more product kits suitable for 
installation on a given hardware or software platform. Figure 2-2 shows a 
generalized illustration of a sample RIS area. 
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Figure 2-2: Sample RIS Area Overview 
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In Figure 2-2, the RIS area /var/adm/ris contains one product 
environment, ris0O.alpha. Each product environment contains products 
for a specific platform. In Figure 2-2, the target platform is machines using 
Alpha processors. Multiple product environments can exist in a single RIS 
area. Each product environment contains one or more product directories, 
each product directory contains several product kit archives, called software 
subsets. Figure 2-2 shows a product environment named risO.alpha 
containing directories called product _001 and product_002. 


Figure 2-2 also shows the kit/is1 directory. The kit/is1 directory 
contains installation tools required by clients when they install software 
over the network. If your environment is in Direct CD-ROM (DCD) format, 
the kit/is1 directory does not exist. An environment in DCD format is the 
same as a system disk format, it includes root, /usr, and soon. 


The server itself usually does not use any of the RIS areas. System 
administrators can access the product area as required for maintenance and 
for installation or removal of product kits. 


For more flexibility, you can establish multiple RIS areas in separate 
partitions. RIS areas on a given server can be exported to other servers 
using the Network File System (NFS). Servers that import such RIS areas 
can use them as if they were local, supplying the imported subsets to their 
own set of clients. Section 4.5 describes how to use NFS to mount a RIS 
area. The Network Administration guide describes how to export and import 
file systems. 


2.4 RIS Client Characteristics 


A RIS installation uses the LAN as its installation media instead of a 
distribution CD-ROM. A RIS client can install any software kit for which 
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it is registered on the server. The installation procedure runs entirely 
on the dient and, after the necessary software is installed, no continuing 
relationship is required between the RIS server and client. 


The operating system itself can be among the kits that are available from the 
server. To install the operating system, the client processor is booted across 
the network using a minimal generic kernel! that is part of the software 

kit. The RIS area is NFS mounted and becomes the client’s root file system 
during the installation. 


Once the client is booted, either the text-based or graphical installation 
interface is launched. After all installation responses are entered, the 
installation software configures the file system, and then uses the set1d 
utility to load the software you selected. For more information about the 
setld utility, refer to the set1d(8) reference page. 


After the installation is complete, the system reboots with the newly 
installed software. For information on installation procedures, refer to the 
Installation Guide 


2.5 Registering Clients 


A client must be registered with only one server for the base operating 
system. If you register a client with more than one server for the base 
operating system, each server the client is registered on will attempt to 
respond to the client’s network boot request with unpredictable results. 


To change the server with which a client is registered for the base operating 
system, first remove the client from the current server's client database and 
then register it with the new server. See Chapter 6 for information about 
registering and removing RIS clients. 


A client can be registered with multiple servers for optional subsets and 
products other than the base operating system. When you load optional 
subsets or layered products with the SysMan Menu, you specify the name 
of the server from which you will copy the kits. 


2.6 Identifying a Client Hardware Network Address 


You need to know your client’s hardware network address when you are 
registering a client toa RIS server. There are several ways to identify this 
information: 


« LogintotheRIS client as root or usethe su command to gain superuser 
privileges, then shut down the system to the console prompt (>>>). 


Use the show dev command to show all devices, and look for 
the hardware address of your network interface in the form 
XX-XX-XX-XX-XxX-xx. For example: 
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>>> show dev 


ewa0.0.0.0.1000.0 EWAO xXxX-XxX-XX-XX-XX-XX 


« LogintotheRIS client as root or usethe su command to gain superuser 
privileges. 


Usethe uerf —r 300 command and look for the string hardware 
address in the ouput. Either that line or the next one contains the 
hardware network address. For example: 


# uer£ -r 300 | grep -i "hardware address" | unig 
_hardware address: XXxX-XxX-XX-XX-XX-XX 


If the hardware address is not on the line that contains the string 
hardware address, search the output from the uerf command to find 
the correct hardware address. For example: 


# uerf -r 300 | more 


_Interface, hardware address: 
_XX- XX-XX-XX-XX-XX 


« Logintothe RIS server as root or use the su command to gain 
superuser privileges. 


Use the ping and arp commands to determine the hardware address 
of a running client from the RIS server. For example, to determine the 
hardware address of the RIS client atlanta, enter a command similar 
to the following example: 


# /usr/sbin/ping -q -cl atlanta ; arp atlanta 

PING atlanta.cities.xsamplex.com (nn.nn.nnn.nnn): 56 data bytes 
----atlanta.cities.xsamplex.com PING Statistics---- 

1 packets transmitted, 1 packets received, 0% packet loss 
round-trip (ms) min/avg/max = 0/0/0 ms 

atlanta (nn.nn.nnn.nnn) at XxX-XxX-XX-XX-XX-XX 
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Preparing the RIS Server 


This chapter provides the steps you must follow to prepare a RIS server. 
These steps include the following: 

Review RIS server/client version compatibility. (Section 3.1) 

Plan disk space for RIS. (Section 3.2) 

Install the operating system on the RIS server. (Section 3.3) 

Set up a local area network. (Section 3.4) 

Load and register the server extensions license. (Section 3.5) 


Au FF WN 


If necessary, prepare RIS for running on a server that has C2 security 
enabled. (Section 3.6) 


3.1 Reviewing RIS Server/Client Version Compatibility 


This section only applies if you are installing a new version of the operating 
system into a RIS environment on a server that is running a previous version 
of the operating system. If not, go to section Section 3.2. 


Perform the following steps to install the operating system into a RIS 
environment on a RIS server running a previous version of the operating 
system: 


1. Login totheRIS server as root, or use the su command to gain 
superuser privileges. 


2. Mount the distribution media. For example, if your distribution media 
isa CD-ROM: 


¢ If you are using an older version of the operating system that uses 
traditional device naming conventions (/dev/rrzNc), use a mount 
command similar to the following example: 


# mount -rd /dev/rz4c /mnt 


This example uses a CD-ROM drive that is unit 4 and specifies 
/mnt as the mount point; if your drive is a different unit, substitute 
the device special file name for that unit. 


The CD-ROM drive's unit number is 4, and in this example is 
/dev/rrz4c. 
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If you do not know your CD-ROM's unit number, refer to Section 1.3. 


¢ If you are using a newer version of the operating system that uses 
newer device naming conventions (/dev/disk/cdromNc), usea 
mount command similar to the following example: 


# mount -rd /dev/disk/cdrom0c /mnt 


This example uses a CD-ROM drive that is unit 0 and specifies 
/mnt as the mount point; if your drive is a different unit, substitute 
the device special file name for that unit. 


The CD-ROM drive's unit number is 0, and in this example is 
/dev/disk/cdromoc. 


If you do not know your CD-ROM's unit number, refer to Section 1.3. 


3. Usetheutilupdate command to update the necessary RIS utilities on 
the server, as shown in the following example: 


# /mnt/isl/utilupdate -r -m /mnt 


¢ The -r option causes the utilupdate utility to copy files from 
the distribution media to the server’s /usr/sbin directory. This 
ensures RIS compatibility with the operating system. 


¢ The-m /mnt argument specifies the mount point of the distribution 
media and is a required parameter. 


This command copies any files in the /usr/sbin directory to files with 
a .pre-V5.0A suffix. For example: /usr/sbin/setld is copied to 
/usr/sbin/setld.pre-V5.0A. 


When the utilupdate script completes, this RIS server can serve the 
current version of the operating system to RIS clients. Appendix C describes 
the utilupdate utility. 


When you are installing the operating system, if the utility finds existing 
* .pre-Vv files on your system, the existing utilities are updated with no 
changes to the saved * .pre-v files. If the server is already running the 
new or updated version of the operating system, a confirmation message is 
displayed and no copies are made. 


After a client’s operating system is installed and running, a server can 
serve additional product subsets to a client running a compatible operating 
system. The client loads the additional subsets with the SysMan Menu. 


A RIS client can be booted by a RIS server by using the BooTP protocol. This 
means that a server can serve both the base operating system as well as 
additional product subsets to the client over the network. The client loads 
additional product subsets with the SysMan Menu. 
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3.2 Planning Disk Space for RIS 


Before beginning to set up a RIS area, you must calculate the amount of disk 
storage required for the software subsets in the RIS areas on the server. If 
space on the server’s system disk is an issue and your server’s distribution 
media is aCD-ROM, you might want to create symbolic links from the RIS 
server area to the software on the CD-ROM. Section 4.2 briefly describes 
the advantages and disadvantages of establishing symbolic links instead of 
extracting the software subsets into the RIS server area. 


See Chapter 1 for a description of the RIS area’s contents. A given server 
can have multiple RIS areas, in which some of the subsets can be duplicated. 
To organize your RIS server’s disk space, perform the following steps: 


Determine how many RIS environments you want. 


Choose the software subsets you want to install, organizing them by the 
environments where they are to be installed. 


3. Usethe subset size information in the Release Notes to ensure that you 
have adequate disk space. 


3.3 Installing the Operating System on the RIS Server 


The Installation Guide describes how to install the operating system on 
the server, and lists all of the supported software subsets along with their 
names and descriptions. This information helps you organize the process 
before you perform the installation. 


Because RIS areas are created in the /var/adm/ris directory, you may 
want to specify a separate /var file system during the installation for extra 
disk space. Refer to the instructions in the Installation Guide to specify a 
separate /var file system. 


Install the Remote Installation Service and Additional 
Networking Services subsets on the system to be used as a RIS Server. 
These subsets contain the tftp networking utility and the joind bootstrap 
daemon. If you want to use the Internet Boot Protocol (BOOTP) server 
daemon boot pd, install the Obsolete Commands and Utilities (Obsolete 
Components) subset OSFOBSOLETES505. 


After you install the operating system, enter the following command to see if 
these subsets are installed: 


# /usr/sbin/setld -i | grep -E "RIS|INET|OBSOLETE" 
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Your output is similar to the following: 


OSFCLINET505 installed Basic Networking Services 

(Network-Server/Communications) 

OSFINETS505 installed Additional Networking Services 

(Network-Server/Communications) 

OSFOBSOLETE505 installed Obsolete Commands and Utilities 
(Obsolete Components) 

OSFRIS505 installed Remote Installation Service 
(Network-Server/Communications) 


The Basic Networking Services subset is mandatory and is installed 
as a mandatory subset when you install the base operating system. If the 
Additional Networking Services, Remote Installation Service, 
Or Obsolete Commands and Utilities subsets are not installed, you 
must install them with the SysMan Menu. 


Refer to the Installation Guide and the sysman(8) reference page for more 
information about installing subsets. 


3.4 Setting Up a Local Area Network 


You must connect the RIS server and all of the dient processors toa LAN 
using either Ethernet, FDDI, or Token Ring. The server and clients all must 
be on the same network or subnetwork unless the router connecting the 
networks or subnetworks can forward BooTP requests. 


For instructions on setting up a local area network, refer to the Network 
Administration guide. 


3.5 Loading and Registering the Server Extensions License 


The Server Extensions license (OSF-SVR Or UNIX-SERVER) provides the 
right to use the RIS software if you are running this operating system. 

A product authorization key (PAK) accompanies the license. You must 
register the PAK information for your system before it can be configured as 
a RIS server. Register the PAK information by using the License M anager 
application. 


Refer to the dxlicense(8) reference page, the SoftwareLicenseM anagenent 
guide, and the License Manager online help for more information about 
registering license PAKs. 


After you have registered the PAK information, you can complete the server 
setup tasks described in Chapter 4. 
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3.6 Preparing RIS for C2 Security 


If your RIS server will have C2 security enabled, the ris user file must be 
changed to ensure that the ris password does not expire and deny client 
access. 


Perform the following steps on the RIS server as superuser to modify the 
ris user file if you are going to use RIS with C2 security enabled: 


1. Edit thefile /tcb/files/auth/r/ris. Each field is delimited by 
a colon (:). 


2. Set the current password field u_pwd toan asterisk (*). 


Set the u_succhg value to any non-zero value. This valueis atime t 
type printed with $1d. 


4. Set theu_life and u_exp fields to zero. 


The following is an example of a modified /tcb/files/auth/r/ris user 
file: 


ris:u_name=ris:u_id#11:\ 
u_oldcrypt#0:\ 
u_pwd=*:\ 
u_exp#0O:u_life#0:\ 
u_succhg#79598399: \ 
u_suclog#79598399:\ 
u_lock@:chkent: 


After you make these changes, the RIS password should not expire and 
cause a denial of service to clients. 
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Setting Up a RIS Area 


This chapter describes how to use the ris utility to configure a RIS server. 
This chapter includes the following topics: 


¢ Establishing a new RIS area with the ris utility (Section 4.2) 

e Installing software kits in an existing RIS area (Section 4.3) 

¢ Including hardware product kits into an existing RIS area (Section 4.4) 
e« Usinga RIS area mounted on NFS (Section 4.5) 


« Modifying the /etc/exports file, if necessary, to export RIS areas 
(Section 4.6) 


4.1 Overview 


The ris utility can be invoked in two ways: 
e Interactively through a menu-driven interface 


¢ From the command line by issuing commands to perform the various 
tasks one at a time 


This chapter describes how to use the ris utility’s menu-driven interface 
Chapter 6 describes how to use individual ris commands. For additional 
information on the ris utility, refer to the ris(8) reference page. 


4.2 Installing Software into a New RIS Area 


After you create a RIS area and install the first software kit there, you can 
install more kits into that area or create other areas as you need them. 
Section 4.3 describes how to install additional software into an existing 
RIS environment. 


Follow these steps to create a new risN .alpha environment and install 
the operating system: 


1. Loginas root or use the su command to gain superuser privileges. 


2. Insert the Operating Systen Volume 1 CD-ROM into the drive, then 
mount the CD-ROM. 
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e If your server is running the current version of the operating system, 
use a command similar to the following example: 


# mount -rd /dev/disk/cdrom0c /mnt 


This example mounts a CD-ROM drive that is device 0 on the mount 
point /mnt . If your driveis a different device, substitute the correct 
device name. The mount point does not have to be /mnt. 


Refer to Section 1.3 if you do not know the CD-ROM drive's device 
name. 


e If your server is running an earlier version of the operating system, 
use a command similar to the following example: 


# mount -rd /dev/rz4c /mnt 


This example uses a CD-ROM drivethat is unit 4 and specifies /mnt 
as the mount point. If your drive is a different unit, substitute the 
device special file name for that unit. 


Refer to Section 1.3 if you do not know the CD-ROM drive's device 
name. 


Note 


You can use a Network File System (NFS) mount point to 
install software from a Remote Installation Services (RIS) 
area or Operating System Volume 1 CD-ROM from another 
processor. Refer to Section 4.5 for more information about 
using an NFS mounted RIS area. 


3. Enter /usr/sbin/ris tostart the ris utility. You seetheRIS Utility 
Main Menu: 


*** RIS Utility Main Menu *** 
Choices without key letters are not available. 


) ADD a client 

) DELETE software products 
) INSTALL software products 
) LIST registered clients 

) MODIFY a client 
) 

) 

) 


nk 


REMOVE a client 


SHOW software products in remote installation environments 
EXIT 


x 


Enter your choice: 
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TheRIS Utility Main Menu does not display option letters for menu 
items that cannot be accessed. As you add environments, software, and 
clients to the system, other menu options become available. 


Enter i toselect Install software products. You see the following 
prompt: 


RIS Software Installation Menu: 


1) Install software into a new area 
2) Add software into an existing area 
3) Return to previous menu 


Enter your choice: 


Enter 1 toselect Install software into a new area. You see 
the following prompt: 


You have chosen to establish a new remote installation 
environment . 


Enter the device special file name or the path of the directory 
where the software is located 


(for example, /mnt/ALPHA/BASE) : 


Enter the full pathname or the device special file name for the 
distribution media. 


¢ If your distribution media is CD-ROM mounted on /mnt, the 
directory where the software is located is /mnt /ALPHA/BASE. 

e« Enter a device specific file name only for magnetic tape media. 

You see the following prompt: 

Select the type of operating system base product to create. If the software you 

are offering supports add-on hardware that is needed to boot the client 

system, select "boot-link" as the type of RIS area to create. Otherwise, 

select "standard". If you select "boot-link", the software will be extracted 

(or copied) to the RIS area because symbolically linked RIS areas do not 

support this feature. 


Choose one of the following options: 


1) Standard boot method 
2) Boot-Link method 


Enter your choice: 


Select one of the available options. 


¢ Select Boot-Link method if you are adding a hardware product 
kit to this RIS area. 


¢ Ifyouselect Standard boot method, you see the following prompt: 
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Choose one of the following options: 


1) Extract software from /mnt/ALPHA/BASE 
2) Create symbolic link to /mnt/ALPHA/BAS! 


La 


Enter your choice: 


If you select Create symbolic link, the ris utility creates 
symbolic links from the RIS area to the subset directories on the 
specified source. Disk space planning is not required because 
the subsets do not reside in the RIS area. The source must be on 
line and mounted for clients to access the subsets. Unlike subset 
extraction, no subset selection is required. Clients registered for 
symbolically linked RIS product areas can access all subsets. 


Caution 


If you unmount, delete, or switch the source where 
the RIS area is linked, the RIS area is corrupted. 
Remount the source to restore the RIS area. 


If you select Extract software, the ris utility copies the 
selected subsets from the source into the RIS area. You must 
know the specific subsets to extract and whether there is 
sufficient disk space. Refer to Section 3.2 for information about 
planning disk space for RIS. 


Clients can install only the subsets that are extracted into 
RIS product areas where they are registered. Using extracted 
subsets improves RIS environment performance. 


The ris utility lists the mandatory and optional software 
subsets you can install. Select the subsets that you want to 
extract; the ris utility displays your list for confirmation. For 
example: 

The following subsets are mandatory and will be installed 


automatically unless you choose to exit without installing 
any subsets: 


{mandatory subset list} 


Optional subsets are listed below. There may be more optional 
subsets than can be presented on a single screen. If this is 
the case, you can choose subsets screen by screen, or all at 
once on the last screen. All of the choices you make will be 
collected for your confirmation before any subsets are installed. 


foptional subset list} 
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The following choices override your previous selections: 
74) ALL mandatory and all optional subsets 

75) MANDATORY subsets only 

76) CANCEL selections and redisplay menus 


Choices (for example, 1 2 4-6): 74 


The following subsets will be loaded: 
{selected subset list - all mandatory & optional in this example} 


Are these the subsets that should be loaded (y/n) ? 


If you enter y, the ris utility loads the subsets. If you enter n, 
the list of subsets is displayed again and you can restart your 
selection process. 


When you confirm your selections, the ris utility extracts the 
subsets and displays the name of the new RIS environment. 


If you are installing a product that is not part of the base operating system 
in the RIS environment, the ris utility tries to determine the system 
architecture. If it cannot, you see a prompt similar to the following example: 


Choose the architecture of the clients that the environment 
will serve: 


1) alpha 
2) custom 
3) mips 


Enter your choice: 1 


The new environment is in /usr/var/adm/ris/ris0.alpha. 


Once you set up theRIS areas and register clients in those areas, the clients 
can access the areas they need. Refer to Chapter 6 for a discussion of client 
registration. 


4.3 Installing Software into an Existing RIS Area 


Follow these steps to install software subsets into an existing RIS 
environment. The subsets must be compatible with the set1d utility. This 
means that the kit was produced in accordance with the instructions in 
the Guide to Preparing Product Kits. 

1. Login as root or use the su command to gain superuser privileges. 


2. Enter /usr/sbin/ris tostart the ris utility. You see the RIS Utility 
Main Menu: 


*** RIS Utility Main Menu *** 
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Choices without key letters are not available. 


a) ADD a client 
d) DELETE software products 
i) INSTALL software products 
) LIST registered clients 
) MODIFY a client 
) REMOVE a client 
s) SHOW software products in remote installation environments 
x) EXIT 


Enter your choice: 


3. Enter itoselect INSTALL software products. You seetheRIS 
Software Installation Menu: 


RIS Software Installation Menu: 


1) Install software into a new area 
2) Add software into an existing area 
3) Return to previous menu 


Enter your choice: 


4. Enter 2 toselectAdd software into an existing area. You seea 
list of the existing RIS areas, similar tothe following example: 


You have chosen to add a product to an existing environment. 
Select the remote installation environment: 


1) /usr/var/adm/ris/ris0O.alpha 
‘POLYCENTER Advanced File System’ 
'DECsafe Available Server Environment (ASE) ’ 
'System V Environment’ 


2) /usr/var/adm/ris/risl.alpha 
‘Sort Runtime Library’ 
'Free Software Foundation GNU Source (Rev nnn)’ 
‘DEC Ada Support Library’ 


Enter your choice or press RETURN to quit: 
5. Enter a number to select the corresponding RIS area. 


6. Continue to mount distribution media and choose subsets as described 
in Section 4.2 . Press the Return key if you want to return tothe RIS 
Utility Main Menu. 


Repeat this procedure for each additional group of subsets you want to 
install. 
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4.4 Including Hardware Product Kits into a RIS Area 


In addition to the base operating system, you may need to install hardware 
product kits onto client systems from the RIS server. For example, a 
hardware product kit can be a third-party driver for a device not supported 
in the base operating system. The ris utility lets you include hardware 
product kits intoa RIS area for subsequent installation onto a client system. 


Setting up a RIS area to serve hardware product kits is subject to the 
following requirements: 


Hardware product kits can be installed only into an extracted RIS area 
that has been set up for bootlinking. You cannot install a hardware 
product kit into a RIS area containing a symbolically linked base 
operating system. 


The hardware product kit must be compatible with the set1d utility to 
be installed into an existing RIS environment. This means that the 
kit was produced in accordance with the instructions in the Guide to 
Preparing Product Kits. 


At a minimum, the extracted RIS area where you install a hardware 
product kit must contain all mandatory subsets. 


Follow this procedure to install a hardware product kit into an existing 
RIS environment: 


Login as root or use the su command to gain superuser privileges. 
Start the ris utility: 


# /usr/sbin/ris 
You see the RIS Utility Main Menu: 


*** RIS Utility Main Menu *** 
Choices without key letters are not available. 


ADD a client 

DELETE software products 

INSTALL software products 

LIST registered clients 

MODIFY a client 

REMOVE a client 

SHOW software products in remote installation environments 
EXIT 


HH: OQ © 


YR SB 


) 
) 
) 
) 
) 
) 
) 
) 


x 


Enter your choice: 


Enter i toselect INSTALL software products. You seetheRIS 
Software Installation Menu: 
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RIS Software Installation Menu: 


1) Install software into a new area 
2) Add software into an existing area 
3) Return to previous menu 


Enter your choice: 


4. Enter 2 toselect Add software into an existing area. You see 
the following prompt, including all available RIS environments: 


You have chosen to add a product to an existing environment. 
Select the remote installation environment: 


1) /var/adm/ris/risl.alpha 
‘Tru6é4 UNIX V5.0A Operating System (Rev nnn )’ 


Enter your choice or press RETURN to quit: 


5. Enter 1 (in this example) to specify the RIS environment where you will 
add the hardware product kit. You see the following prompt: 
Enter the device special file name or the path of the directory where 
the software is located (for example, /mnt/ALPHA/BASE) : 
6. Enter the location of the hardware product kit you are adding, for 
example: /HWKIT/MYVGA. You see the following prompt: 
The kit you have specified has been identified as a kernel kit. 
This type of kit may contain software which is needed during the booting of 
the kernel for the installation due to required hardware support. If you need 


to add this kit to the base, select the option to integrate the kit. You may 
otherwise choose to add this kit to the RIS area as a separate product. 


1) Integrate with Base product and include product 
2) Include as separate product 


3) Return to Main Menu 


Enter your choice: [1]: 


7. Select 1 to integrate the software with the base product. You see the 
following prompt: 


Please select one of the following products to add the kit to. 


1. ‘Tru64 UNIX V5.0A Operating System (Rev nnn)’ 


Enter your selection or <return> to quit: 


8. Select 1 (in this example) to select the base product where you will 
integrate the hardware product kit. 
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10. 


11. 


You see the following prompt: 


Choose one of the following options: 


1) Extract software from /HWKIT/MYVGA/kit 
2) Create symbolic link to /HWKIT/MYVGA/kit 
Enter your choice: 


Select 1 to extract the software. You see the following prompt: 


[The subsets listed below are optional: 


[There may be more optional subsets than can be presented on a single 
screen. If this is the case, you can choose subsets screen by screen 
or all at once on the last screen. All of the choices you make will 

be collected for your confirmation before any subsets are extracted. 


1) MYVGA Test kit 

Or you may choose one of the following options: 
2) ALL of the above 
3) CANCEL selections and redisplay menus 


4) EXIT without extracting any subsets 


Enter your choices or press RETURN to redisplay menus. 
Choices (for example, 1 2 4-6): 


Select 1 (in this example) to select the subset. You see the following 
prompt: 


You are extracting the following optional subsets: 
MYVGA Test kit 
Is this correct? (y/n): 


Select y to confirm your selection. You see a prompt similar to the 
following: 

Checking file system space required to extract selected subsets: 

File system space checked OK. 

Extracting MYGASTATIC100... 


Media extraction complete. 


The following software now exists in RIS product area 
/var/adm/ris/risl.alpha: 


1 'Tru6é4 UNIX V5.0A Operating System (Rev nnn)’ 
with ‘MYVGASTATIC software version 1’ 
2 ‘MYVGASTATIC software version 1’ 


The hardware product kit is now installed into the newly-created RIS 
product area. 
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4.5 Using a RIS Area Mounted on NFS 


You can use an NFS mount point to install software from an extracted RIS 
area on another system or from an operating system distribution CD-ROM 
mounted on another system. You can use this method to create an extracted 
RIS area with the base operating system subsets. 


Caution 


The information in this section can be used only if you are 
installing software on a client after you install the operating 
system software. 


For example, if a system named chicago has a CD-ROM containing the 
operating system subsets mounted on /mnt and listed inits /etc/exports 
file, the system administrator on newyork can use mount that CD-ROM 
with a command similar to the following example: 


NYroot# mount chicago:/mnt/ALPHA/BASE /mnt 


After chicago is mounted, the newyork system administrator can use the 
ris utility toinstall software from the CD-ROM as if it were local to the 
newyork system. 


If another system exports an extracted RIS area with the subsets you need 
on a local system, you can create an extracted RIS area from the remote RIS 
area. For example, if a system named seattle has the operating system 
subsets in its risO0.alpha product environment, the system administrator 
on newyork can NFS mount that product environment with the following 
command: 


NYroot# mount seattle:/var/adm/ris/risO.alpha /mnt 


After the remote product environment is mounted, the system administrator 
for newyork can use the ris utility to install software from it as if it were 
local to newyork. 


4.6 Modifying the /etc/exports File 


RIS client installations of the base operating system prior tothis version rely 
on files located in the server's /var/adm/ris/risN.arch/kit directories. 
TheRIS server must export these directories. 


For this version of the operating system base product, the 
/var/adm/ris/risN.arch/product_1 product directory that is exported 
contains the distribution image. In this directory path, nis the number of 
the RIS area and arch is the architecture of the client systems that the 
area serves. 
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When you create the risN. arch RIS area, the ris utility supplies you with 
a name based on the choices you make when you create the RIS area. 


The server’s /etc/exports file must include an entry for each RIS 
area that it is exporting. When you create a RIS area, the ris utility 
automatically edits the /etc/exports file and adds the correct entry for 
that area. However, if you modify the path to a RIS area, you must also 
modify the corresponding line in the /etc/exports file. 


TheRIS area entries in the /etc/exports file of a system that acts as a 
RIS server for two Alpha environments look similar to the following: 


/var/adm/ris/risO.alpha/kit -root=0 -ro 
/var/adm/ris/risl.alpha/kit -root=0 -ro 

/vis/r2pl1 -root=0 -ro 

This example shows a /ris/r2p1 entry in /etc/exports. This 
entry is created by RIS and is a symbolic link from /ris/r2p1 to 
/var/adm/ris/ris2.alpha/product_1. This link shortens the path 
sent to the client during the boot process. 


When you create a /risN .alpha area, the path to the kit directory 
is /var/adm/ris/ris0O.alpha/kit and the ris utility places the 
following linein the /etc/exports file: 


/var/adm/ris/risO.alpha/kit -root=0 -ro 


If you create another directory in this RIS area, for example, dsk1, 
mount another file system there, move the contents of risO.alpha to 
that directory, and then link it torisoO.alpha, a listing of the RIS area 
shows the following entry: 


risO.alpha -> ./dsk1/ris0O.alpha 


The path to the kit directory is now effectively 
/var/adm/ris/dsk1/risO.alpha/kit. You must edit the 
corresponding line in the /etc/exports file, as shown in the following 
example: 


/var/adm/ris/dsk1/ris0O.alpha/kit -root=0 -ro 


If you do not edit the /etc/exports filein this case, you will havea kit 
directory mount failure when you attempt a client installation. 
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Booting a RIS Client 


You must register a RIS client on the RIS server before you can use RIS to 
install the operating system on the RIS client. If you use RIS toinstall the 
operating system on a client, the client must boot across the network by 
issuing a BOOTP request. This chapter includes the following topics: 


¢ Describing remote boot files and daemons (Section 5.1) 
¢« Explaining the remote boot process flow (Section 5.2) 


5.1 Remote Boot Files and Daemons 
Several files and daemons are associated with booting a RIS client over the 
network. This section includes the following topics: 


¢ The inetd internet daemon and its configuration file, inetd. conf 
(Section 5.1.1) 


¢« Theinternet boot protocol (BOOTP) joind daemon (Section 5.1.2) 
¢ The /etc/bootptab file (Section 5.1.3) 
¢ TheTFTP daemon t£tpd (Section 5.1.4) 


Refer to the following reference pages for more information: 


bootptab(4) 
inetd. con£(4) 
inet(7) 
inetd(8) 
joind(8) 


Table 5-1 describes the files and daemons used by RIS servers to boot a 
remote client. 


Table 5-1: Remote Boot Files and Daemons 


Name Description 
/etc/bootptab Contains information needed to boot remote clients 
/etc/inetd.conft Contains start-up information for various 


internet daemons 


/sbin/init.d/dhcp — Script used to start joind 
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Table 5-1: Remote Boot Files and Daemons (cont.) 


Name Description 
/usr/sbin/inetd The Internet server daemon 
/usr/sbin/joind The BOOTP server daemon (handles both BOOTP 


and DHCP requests, if configured) 


/usr/sbin/tftpd The tftpd server daemon 


5.1.1 The Internet Daemon and Configuration File 


The inetd internet daemon starts networking-related daemons on the 
system. Some of these daemons, such as tf£tpd, are related to RIS; others, 
such as fingerd, are not. On request, the inetd daemon starts any of the 
daemons listed in its configuration file, /etc/inetd. conf. 


Network boots use the BOOTP protocol and are serviced by the joind 
daemon, discussed in Section 5.1.2. 


5.1.2 The BOOTP Daemon 


The internet boot protocol (BOOTP) daemon joind processes any BOOTP 
requests received by the RIS server. As it starts, the BOOTP daemon 
reads the /etc/bootptab file to determine the systems from which it 
will recognize remote boot requests. Whenever the /etc/bootptab file is 
modified, the BOOTP daemon rereads it. 


The joind daemon provides configuration to network clients using either 
BOOTP or the Dynamic Host Configuration Protocol (DHCP). If joind is 
not running, RIS restarts it with the /sbin/init.d/dhep Script. 


Section 5.1.3 describes the content and format of the /etc/bootptab 
file. Refer tothe boot ptab(4) and dhcptags(4) reference pages for more 
information. 


5.1.3 The /etc/bootptab File 


The /etc/bootptab file is a text file containing information that a server 
needs to boot a remote client. The ris utility adds and removes entries from 
this file during client management. Other applications may place entries 

in the /etc/bootptab file. 


Example 5-1 describes the entries in an /etc/bootptab file for RIS clients. 
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Example 5-1: Sample /etc/bootptab File 


.vis.dec:hn:vm=rfc1048 |1 
.risO.alpha:tc=.ris.dec:bf=/var/adm/ris/ris0O.alpha/vmunix: |2 
atlanta:tc=.ris0O.alpha:ht=ethernet:gw=nn.nn.nnn.nnn: \ 
ha=nnnnnnnnnnnn:ip=nn.nn.nnn.nnn : |8 
.vis93.alpha:tc=.ris.dec:bf=/ris/ris93.a/vmunix: \ 
rp="ds9:/ris/ris93.a/product_001": |4 


1] The .ris.dec entry defines characteristics common to all clients. The 
fields specify the following: 


* hn: Tells the boot server to send the name of the client system to the 
client when it makes a boot request. 


e vm: Vendor-specific information 


2) The .risN.arch entry, in this example .ris0.alpha, defines 
characteristics common to all clients using this RIS area. The fields 
specify the following: 


¢ tc: Table continuation 


The tc field lets you follow pointers back to common entries. F or 
example, the tc entry for .risO0.alpha in Example 5-1 points to 
the .ris.dec entry. The .ris.dec entry contains the common 
hardware type (ht) and vendor specific (vm) information. The 
.ris0O.alpha entry, itself, contains common information about the 
boot file location. 


¢ bf: Name of the boot file 


3] The hostname entry, in this example atlanta, defines characteristics 
for a specific dient. The fields specify the following: 


¢ tc: Table continuation 


The following describes the entry for the host atlanta: its tc entry 
points to ris0.alpha, which contains its boot file information. The 
ris0.alpha entry in turn points back to ris.dec, which contains 
relevant hardware type and vendor specific information. If you 
added another host entry to the /etc/bootptab file, it would look 
similar to the following: 


lee:tc=ris0O.alpha:ht=ethernet:ha=nnnnnnnnnnnn : \ 
ip=nn.nn.nnn.nnn : 


¢« ht: The client’s hardware type is either ethernet, fddi, or 
ieeeso2 (for Token Ring) 
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* ha: Client’s network hardware address 
* ip: Client’s IP address 


4) The .ris93.alpha entry defines characteristics for the current version 
of the operating system RIS area. The fields specify the following: 


¢ tc: Table continuation 


The tc field lets you follow pointers back to common entries. F or 
example, the tc entry for .ris93.alpha in Example 5-1 points to 
the .ris.dec entry. The .ris.dec entry contains the common 
hardware type (ht) and vendor specific (vm) information. The 
.ris93.alpha entry contains common information about the boot 
file location. 


* bf: Name of the boot file 
¢ rp: Theclient will mount its root on the server. 


The general format for entries in the bootptab file is a 1abe1 followed 
by one or more colon-separated fields. Each of these fields consists of a 
two-character tag field tg followed by an equal sign (=) and the tag value 
value: 


[label] :tg[=value] [:tg[=value] :...] 


For additional information about the contents of the boot ptab file, refer to 
the boot ptab(4) reference page. For information about valid tg tags, refer 
to the dhcptags(4) reference page. 


5.1.4 The tftpd Daemon 


Thetftpd daemon uses the Trivial File Transfer Protocol (TFTP) to transfer 
the boot file during a remote boot process. The tf£tpd daemon starts when a 
file is ready to be transferred. Refer tothe t£tp(1) and t£tpd(8) reference 
pages for more information. 


5.2 Remote Boot Process Flow 
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Client systems use the bootp protocol to perform the remote boot operation 
froma RIS server. The command used to initiate a remote boot is 
processor-specific. For additional information, refer to the Installation Guide 
— Advanced Topics. However, once the remote boot operation has started, 
the underlying process is the same for all versions of the operating system 
that support network booting: 


1. The processor-specific remote boot command is issued at the client 
console prompt. 


2. Theclient processor firmware sends a BOOTP packet over the Ethernet 
contining the client’s hardware Ethernet address. 
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3. TheBOOTP server daemon compares the Ethernet hardware address 
in the packet with the client registration information stored in its 
/etc/bootptab file to determine if the client requesting the remote 
boot is registered to the RIS server. 


4. \|famatching address is found in the /etc/bootptab file, the BOOTP 
daemon sends the client an information packet that includes the 
server’s Internet address, the client’s Internet address, and the name 
of the file to be loaded from the server. This information was placed in 
the bootptab file by the ris utility when the client was registered 
on the RIS server. 


Internet addresses are used to download the 
/var/adm/risN.alpha/vmunix file specified in the bootptab file to 
the client processor, where risN.alpha corresponds tothe RIS area 
to which the client is registered. This file contains the standalone 
operating system used to start the installation. 


The client system requests the file from the server system. 


The client and server system use the TFTP protocol to transfer the 
vmunix file to the client. 


7. Once vmunix is loaded, the client system begins to execute the vmunix 
file, and the operating system standalone system messages are 
displayed on the client console terminal. 


After the operating system is installed, the client is a self-supporting system. 
Follow the procedures documented in the Installation Guide to boot the 
system from its own local disk. 
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Managing RIS Clients and Environments 


Use the ris utility to manage RIS environments and clients. This chapter 
includes the following topics: 


¢ Preparing to register RIS clients (Section 6.1) 

e« Adding a client with the ris utility (Section 6.2) 

e Adding a client from the command line (Section 6.3) 

¢« Modifying a client (Section 6.4) 

« Removing a client (Section 6.5) 

e Listing registered clients (Section 6.6) 

¢ Listing software products in RIS areas (Section 6.7) 

¢ Deleting software products from RIS areas (Section 6.8) 
¢ Correcting entries in the RIS gateways file (Section 6.9) 


6.1 Preregistration Tasks 


Before you register RIS clients, gather the information required for each 
one. TheRIS Client Configuration Worksheet in Appendix A will help you 
organize your information as you register clients. Fill out a worksheet for 
each client you want to register. 


Perform the following tasks to prepare to register clients: 


1. Obtain information about each client and fill out a copy of the RIS Client 
Configuration Worksheet from Appendix A. (Section 6.1.1) 


2. Register each client’s host name and Internet Protocol (IP) address in 
the RIS server’s /etc/hosts file and on your local area network with 
any name servers for Berkeley Internet Name Domain (BIND) Service 
and Network Information Service (NIS). (Section 6.1.2) 


6.1.1 Obtaining Information About Each Client 


You need the following information about each processor you plan to register 
as a client: 


¢« Host name (refer to Section 6.2 for host name restrictions) 
¢ TheRIS environments you want to make available to the client 
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¢ The client’s hardware network address 


e« Theaddress of the gateway from the client to the server, if the server 
and client are on different networks 


¢ The type of network where the client is connected: Ethernet, FDDI, 
or Token Ring 


¢ Whether or not you want to use a profile set during installation (refer to 
Chapter 7 for information about profile sets) 


6.1.2 Registering Client Host Names and IP Addresses 
Make sure that your clients are registered with the naming services 
available on your LAN: 
« TheRIS server’s /etc/hosts file 
e« Any Berkeley Internet Name Domain (BIND) server 
e« Any Network Information Services (NIS) server 


Use the Network Configuration Application to place each client processor’s 
host name and IP (Internet Protocol) address in the /etc/hosts file when 
you first set up your LAN. Refer to the Network Administration manual for 
information about the Network Configuration Application. 


You also can place the host name and IP address in the /etc/hosts file 
with a text editor such as vi. The host name and IP address for each 
client processor must be unique. Refer to the hosts(4) reference page for 
information about the /etc/hosts file. 


Refer to the Network Administration guide for information about setting up 
NIS and the BIND Configuration Application. 


6.2 Adding a RIS Client with the ris Utility 
Follow this procedure to add a RIS client: 


1. Loginas root or usethe su command to gain superuser privileges. 


2. Enter /usr/sbin/ris tostart the ris utility. You see the RIS Utility 
Main Menu: 


*** RIS Utility Main Menu *** 
Choices without key letters are not available. 


ADD a client 

DELETE software products 
INSTALL software products 
LIST registered clients 


) 
) 
i) 
) 
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) MODIFY a client 

) REMOVE a client 

s) SHOW software products in remote installation environments 
x) XIT 


ea 


Enter your choice: 

3. Enter atoselect ADD a client. You see the following prompt: 
You have chosen to add a client for remote installation services. 
The following conditions must be met to add a client: 


1. You must know the client processor’s hostname. 

2. The client’s hostname must be in your system’s host 
database(s) . 

3. You must know whether the client is on an Ethernet, FDDI, 
or Token Ring network. 

4. You must know the client’s hardware Ethernet, FDDI, or 
Token Ring address if the client is registering to install 
operating system software. 

5. If the client and the server reside on different subnets, 
you will need the address of the gateway (s) 
that the client can use to communicate with the server. 


Do you want to continue? (y/n) [y]: 


4. Enter y tocontinue. You see the following prompt: 


Enter the client processor’s hostname: clientl 


5. Enter the client’s host name. 


Caution 


Only lowercase letters (a-z), numerals (0-9), and the period 
(.) and dash (- ) characters are permitted in host names, 
which must begin with a letter. Invalid host names can 
corrupt the RIS database. The client must not be registered 
on another RIS or DMS server as a client. 


The client processor must be registered with the appropriate 
naming service (Section 6.1.2) or you cannot register the 
client with RIS. If the client is not registered with the 
appropriate naming service, the ris utility displays an error 
message and repeats the prompt. 


6. What you see next depends upon whether you have hardware product 
kits installed on your RIS server. 


¢ If you do not have hardware product kits installed on your RIS 
server, you see a prompt similar to the following, which shows (in 
this example) two RIS environments: 
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Select the remote installation environment: 


1) /usr/var/adm/ris/ris2.alpha 
‘Tru6é4 UNIX V5.0 Operating System (Rev nnn)’ 


2) /usr/var/adm/ris/ris3.alpha 
‘Tru64 UNIX V5.0A Operating System (Rev nnn)’ 


Enter your choice or press RETURN to quit: 


a. Enter the RIS environment where you want to add the client, 
for example: 2. You see a prompt similar to the following: 


Select one or more products for the client to install 
from /usr/var/adm/ris/ris3.alpha: 


Product Description 
1 ‘Tru64 UNIX V5.0A Operating System (Rev nnn)’ 


Enter one or more choices as a space-separated list 


(for example, 1 2 3) or all for all products [all]: 


b. Enter the number of the product you want this client to be 
able to install, for example: 1. You see a prompt similar to 
the following: 


You chose the following products: 
1 ‘Tru64 UNIX V5.0A Operating System (Rev nnn)’ 


Is that correct? (y/n) [yl]: 


e If you have hardware product kits installed on your RIS server, you 
see a prompt similar to the following, which shows (in this example) 
one RIS environment: 


The existing environment is /var/adm/ris/ris0O.alpha. 


Select one or more products for the client to install 
from /var/adm/ris/ris0O.alpha: 


Product Description 
1 ‘Tru64 UNIX V5.0A Operating System (Rev nnn )’ with 
'MYVGASTATIC software version 1’ 
2 'MYVGASTATIC software version 1’ 


Enter one or more choices as a space-separated list 
(for example, 1 2 3) or "all" for all products [all]: 


Enter all. 
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Caution 


You must enter all for the new hardware support to be 
loaded during the installation process. 


You see a prompt similar to the following: 


You chose the following products: 


ils ‘Tru64 UNIX V5.0A Operating System (Rev nnn )’ with 
‘MYVGASTATIC software version 1’ 
2 ‘MYVGASTATIC software version 1’ 


Is that correct? (y/n) [yl]: 


Enter y to confirm your selection. 


What happens next depends upon whether profile sets reside on the RIS 
server. Refer to Chapter 7 for information about profile sets. 


If no such profile sets reside on the RIS server, the ris utility 
proceeds to the next step. 


If profile sets reside on this RIS server, you see the following prompt: 


Do you want to specify an Installation Profile Set for use 
during the installation of this client? [y/n] [nl]: 


Choose one of the following options: 


- Enter nif you do not want to specify a profile set for Installation 
Cloning. The ris utility proceeds to the next step. 


- Enter y tospecify a profile set for Installation Cloning. You seea 
prompt similar to the following: 


This RIS server has the following Installation Profile Sets available: 
Astation400 Astation400a rz26 


Enter a set name or press <Return> to exit set selection: 


If you select a profile set, the ris utility validates it before 
proceeding. If you do not want to select an available profile 
set, press Return. 


You see the following prompt: 


Network type: 


1) Ethernet or FDDI 
2) Token Ring 


Enter your choice: 
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9. Select the type of network where the client is connected, for example: 
1 for Ethernet. 


e |ftheserver and client are connected to the same network, the ris 
utility proceeds to the next step. 


e |ftheserver and client are on different networks, the ris utility 
looks at the /var/adm/ris/gateways file and displays the 
gateway information needed for the client to connect to the server: 
Using nn.nn.nnn.nnn for gateway address between client and server subnet. 


If this gateway address is incorrect, please refer to the Sharing Software 
on a Local Area Network book for information on how to correct it. 


If the displayed gateway address is incorrect, follow the instructions 
in Section 6.9 to correct this information. 


¢ If you selected the base operating system for the RIS client toinstall, 
you see the following prompt: 


Enter the client processor’s hardware network address. 
For example, 08-00-2b-02-67-e1: 


Enter the RIS client’s hardware network address. 


- If you do not know the RIS client’s hardware network address, 
refer to Section 2.6. 


- If you are adding a duster member as a RIS client, enter the 
cluster member’s actual hardware network address. 


- If you are adding a cluster alias as a RIS client, enter a fictitious 
hardware address, for example: 00-00-00-00-00-01. 


Caution 


If you do not enter the address in the correct format, the 
ris utility displays an error message and repeats the 
prompt. The ris utility checks your entry's format but 
does not verify its validity. 


You see a message similar to the following: 


Client clienti1 has been added. 
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6.3 Adding a RIS Client from the Command Line 


You can add a single RIS client from the command line by invoking the ris 
utility with its—a option. Other options supply the network address, path, 
and product list. Use the following syntax for the ris utility: 


/usr/sbin/ris -a clientname -h network-address -p path,product [,product...] 
For example: 
# /usr/sbin/ris -a fargo -h xx-xx-xx-xxX-xXX-XxX 


-p ris0O.alpha,prod 001 


6.4 Modifying RIS Clients 


You can modify a RIS client’s network type, hardware network address, its 
RIS environment information, and the list of products it can install. You 
cannot modify a client’s IP or routing information. To modify a client’s entry, 
follow these steps: 

Login as root or use the su command to gain superuser privileges. 

Start the ris utility: 

# /usr/sbin/ris 


You see the RIS Utility Main Menu: 


*** RIS Utility Main Menu *** 


Choices without key letters are not available. 


a) ADD a client 

d) DELETE software products 

i) INSTALL software products 

1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software products in remote installation environments 
x) EXIT 


Enter your choice: 


3. Entermtoselect MODIFY a client. You seea prompt similar tothe 
following: 


The following clients are available to modify: 


client01 client02 client03 client04 


Enter the client processor’s hostname or press RETURN to quit: 
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4. Enter the client name, for example: client01. You see a prompt 
similar to the following: 


Select the remote installation environment: 


1) /var/adm/ris/ris10.alpha 
‘Tru64 UNIX V5.0 Operating System ( Rev nnn )’ 


2) /var/adm/ris/risll.alpha 
‘Tru6é4 UNIX V5.0A Operating System ( Rev nnn ) 


Enter your choice or press RETURN to quit: 


5. Enter the number of the RIS environment you want, for example: 2. 
You see a prompt similar to the following: 


Select one or more products for the client to install 
from /var/adm/ris/risll.alpha: 


Product Description 
1 ‘Tru6é4 UNIX V5.0A Operating System ( Rev nnn ) 


Enter one or more choices as a space-separated list 
(for example, 1 2 3) or "all" for all products [all]: 


6. Enter the numbers of the products you want to install, or press Return 
for all products. You see a prompt similar to the following: 


You chose the following products: 
1 ‘Tru6é4 UNIX V5.0A Operating System ( Rev nnn ) 


Is that correct? (y/n) ly]: 


7. Enter y to verify your selection. You see a prompt similar to the 
following: 


Enter the client processor’s hardware network address. For 
example, 08-00-2b-02-67-e1 [xx-xx-xXxX-XX-XxX-xx]: 


8. Enter your client’s hardware network address, or press Return if the 
default is correct. The default is the client’s existing hardware address. 
Refer to Section 2.6 for information about determining a system's 
hardware network address. 


You see the following prompt: 


Do you want to specify an Installation Profile Set for use 
during the installation of this client? [y/n] [nl]: 
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10. 


In this example, enter n. Refer to Chapter 7 for information about RIS 
profile sets. 


You see the following prompt: 


Network type: 
1) Ethernet or FDDI 
2) Token Ring 


Enter your choice [1]: 


Enter your network type, for example: 1 to select Ethernet. You seea 
prompt similar to the following: 


Using nn.nn.nnn.nnn for gateway address between client and 
server subnet. If this gateway address is incorrect, please 
refer to the Sharing Software on a Local Area Network book 
for information on how to correct it. 


Client client0Ol has been modified. 
*** RIS Utility Main Menu *** 


a) ADD a client 


) 
d) DELETE software products 
i) INSTALL software products 
1) LIST registered clients 
m) MODIFY a client 
r) REMOVE a client 
s) SHOW software products in remote installation environments 
x) EXIT 


Enter your choice: 


Note 


To modify a RIS client’s IP or routing information, remove the 
client and add it with the modified information. 


6.5 Removing RIS Clients 


To remove a RIS client, follow these steps: 


Li 
2. 


Login as root or use the su command to gain superuser privileges. 
Start the ris utility: 


# /usr/sbin/ris 


You see the RIS Utility Main Menu: 
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5. 


*** RIS Utility Main Menu *** 


Choices without key letters are not available. 


a) ADD a client 

d) DELETE software products 

i) INSTALL software products 

1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software products in remote installation environments 
x) EXIT 


Enter your choice: 


Enter r toselect REMOVE a client. You seea prompt similar tothe 
following: 


You have chosen to remove a client from the remote installation 
services. 


Enter the client processor’s hostname or press RETURN to quit: 


Enter the client’s host name, for example: client01. You see a prompt 
similar to the following: 


Remove client01? (y/n) [n]: 


Enter y to confirm the removal. You see the RIS Utility Main Menu. 


You also can use a ris command line to remove several clients at once. The 
following example removes the clients boston and tulsa: 


# /usr/sbin/ris -r boston tulsa 


6.6 Listing Registered RIS Clients 


Follow these steps to view registered RIS clients: 


1. 
2. 


Login as root or use the su command to gain superuser privileges. 
Start the ris utility: 

# /usr/sbin/ris 

You see the RIS Utility Main Menu: 

*** RIS Utility Main Menu *** 

Choices without key letters are not available. 

a) ADD a client 


d) DELETE software products 
i) INSTALL software products 
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1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software products in remote installation environments 
x) EXIT 


Enter your choice: 


3. Enter 1 (lower-case L) toselect LIST registered clients. You seea 


message similar to the following: 


The following clients are registered for /var/adm/ris/ris1l0.alpha: 
client02 


The following clients are registered for /var/adm/ris/risll.alpha: 
client01 client03 client04 


6.7 Listing Products in RIS Server Areas 


Follow these steps to list the available product in RIS server areas: 


Login as root or use the su command to gain superuser privileges. 


Start the ris utility: 


# /usr/sbin/ris 
You see the RIS Utility Main Menu: 


*** RIS Utility Main Menu *** 


Choices without key letters are not available. 


a) ADD a client 
d) DELETE software products 
i) INSTALL software products 
) LIST registered clients 
) MODIFY a client 
) REMOVE a client 
s) SHOW software products in remote installation environments 
x) EXIT 


Enter your choice: 
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3. Enter s toselect SHOW software products in remote 
installation environments. You see a prompt similar to the 
following: 


1) /var/adm/ris/ris10.alpha 
‘Tru64 UNIX VAAA Operating System ( Rev nnn )’ 


2) /var/adm/ris/risll.alpha 
‘Tru6é4 UNIX VBBB Operating System ( Rev nnn )' 


You alsocan usethe ris -s command to show the products installed ina 
server's area. For example: 


# /usr/sbin/ris -s 
Show Products in RIS Server Areas: 


1 /var/adm/ris/ris0O.alpha 
Tru6é4 UNIX V5.0A Operating System (Rev nnn) 


6.8 Deleting Products from RIS Server Areas 


To delete one or more of the current products in a RIS area, invoke the ris 
utility and choose the option to delete products. Theutility asks you to choose 
a RIS area and then guides you through the procedure to delete products. 


Login as root or use the su command to gain superuser privileges. 
Start the ris utility: 


# /usr/sbin/ris 
You see the RIS Utility Main Menu: 


*** RIS Utility Main Menu *** 
Choices without key letters are not available. 


) ADD a client 


o 


d) DELETE software products 

i) INSTALL software products 

1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software products in remote installation environments 
x) EXIT 


Enter your choice: 


3. Enter dtoseect DELETE software products. You seea prompt 
similar to the following: 
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Select the remote installation environment: 


1) /usr/var/adm/ris/ris0O.alpha 
‘Product 01’ 
‘Product 02’ 


2) /usr/var/adm/ris/risl.alpha 
‘Product 03’ 
‘Product 04’ 


Enter your choice or press RETURN to quit: 


Enter the number of the RIS area you want, for example: 2. You see a 
prompt similar to the following: 


Select one or more products to delete from 
/usr/var/adm/ris/risl.alpha: 


Product Description 
1 ‘Product 03’ 
2 ‘Product 04’ 


Enter one or more choices as a space-separated list 
(for example, 1 2 3) or "all" for all products: 


Enter the number of the product you want to delete, for example: 1. You 
see a prompt similar to the following: 


You chose the following products: 
1: ‘Product 03’ 


Is that correct? (y/n) [yl]: 
Enter y to confirm your selection. 
RIS does not keep empty RIS areas. If there is only one product in the 
RIS area you selected, the ris utility verifies your intentions. 
a. You seea prompt similar to the following: 
After this deletion, the area /usr/var/adm/ris/risl.alpha will be empty. 
The following clients are registered for /usr/var/adm/ris/risl.alpha: 


client02 


This procedure will remove /usr/var/adm/ris/risl.alpha altogether and 
remove all clients registered to it. Do you wish to continue? (y/n) [n]: 


b. Enter y if you want to delete the product, the RIS area, and all 
clients registered to the RIS area. 


You see the RIS Utility Main Menu. 
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6.9 Correcting RIS Gateways File Entries 


The /var/adm/ris/gateways file contains information about the address 
of the gateway between the client system and the RIS server. When you 
register a new client (Section 6.2), the ris utility queries this file to 
determine if a gateway is already specified for the client’s network subnet. If 
not, you are prompted to supply the IP address of the gateway. 


If you enter the gateway address incorrectly, log in aS root (or 

use the su command to gain superuser privileges) and edit the 
/var/adm/ris/gateways file to correct the entry. Entries in the gateways 
file have the following format: 


subnet_addr:gateway_addr 


Example 6-1 shows a typical /var/adm/ris/gateways file: 


Example 6-1: Sample /var/adm/ris/gateways File 


16.168.64:16.168.64.1 

16.69.240:16.69.224.199 
16.140.144:16.140.144.2 
16.69.144:16.69.144.199 


After you correct the entries in this file, you must use the ris utility to 
remove all clients using the incorrect gateway address and register them 
again. 
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Managing RIS Profile Sets 


A profile set is a logically organized subdirectory of the 
/var/adm/ris/clients/sets directory ona RIS server. It contains 
configuration description files (CDFs) and user-supplied files that can be 
invoked during a Full Installation and used for Installation Cloning. When 
you register a RIS client for a RIS area, you can specify a profile set that 
contains CDF s or user-supplied files that you want to execute when you 
install software from the RIS area. 


This chapter discusses the following topics: 


Creating profile set directories (Section 7.2) 

Registering RIS cients for profile sets (Section 7.3) 
Converting old configuration description files (Section 7.4) 
Determining a RIS client’s profile set registration (Section 7.5) 
Removing a RIS client’s profile set registration (Section 7.6) 
Deleting profile sets from the RIS server (Section 7.7) 


7.1 Overview 


A profile set can contain one or more of the following files: 


The install.cdf file is used for Installation Cloning. 


This file is generated in the /var/adm/smlogs directory when you 
install the current version of the operating system with the F ull 
Installation process. It contains a record of the file system layout, host- 
and site-specific information, and the software that was installed during 
a Full Installation. This information can be used to clone the same 
installation on other systems with similar hardware. 


The config.cdf file is used for Configuration Cloning. 


This file contains network, internet, printer, and mail configuration 
information that has been saved from a fully installed and configured 
system. Usethe sysman -clone -save command to create the 
config.cdéf file whenever you want to save configuration information. 
The config.cdf file can be applied toa target system during a Full 
Installation, or it can be applied manually to a running system. 
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e User-supplied files are a way to extend and customize the installation 
process, and can contain scripts, executables, or programs. The Full 
Installation and Update Installation processes execute user-supplied 
files at predetermined points during the installation. 


User-installed files may include some or all of the following files: 
- preinstall 

- update preinstall 

- postload 

- update _postload 

- postreboot 


e Any files called by the user-supplied files. 


If a RIS client system is registered for a profile set, the Full Installation 
process searches the client system’s registered profile set and takes action if 
it finds any of these user-supplied files. 


You can organize CDF s and user-supplied files into profile sets to support 
different functions or types of systems within your processing environment. 
For example: 


e If you install and configure engineering systems differently from 
accounting department systems, you might create two profile set 
directories: engineering and accounting. Those profile sets would 
contain the CDF s and files you create to suit the configuration needs of 
both departments. 


¢ Ifyou maintain separate CDF s and files for servers and workstations, you 
might create profile set directories named server and workstation. 


Refer to the Installation Guide — Advanced Topics for information about 
Installation Cloning, Configuration Cloning, creating and modifying CDFs, 
and creating user-supplied files. 


7.2 Creating Profile Sets 


The /var/adm/ris/clients/sets directory can contain many profile 
sets. Each of the profile set directories may contain CDFs and user-supplied 
files, as well as any files called by them. 


Use the following procedure to create profile sets: 


1. Logintothe RIS server as root or use the su command to gain 
superuser privileges. 


2. Gotothe profile sets directory: 


# cd /var/adm/ris/clients/sets 
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3. Create the profile set directory. For example: 
# mkdir engineering 


4. Gotothe newly created directory to ensure that the necessary files are 
copied to the correct destination. For example: 


# cd engineering 


5. Copy the CDFs, any user-supplied files, and all other related files from 
your working area tothe new engineering profile set directory usinga 
copy tool such as cp, ftp, or rcp. 


For example, if your CDFs and user-supplied files are in the 
/users/dev/working directory on the same system: 


cp /users/dev/working/install.cdf . 

cp /users/dev/working/config.cdf . 

cp /users/dev/working/preinstall . 

cp /users/dev/working/update preinstall . 
cp /users/dev/working/postload . 

cp /users/dev/working/update postload . 
cp /users/dev/working/postreboot . 


Heo HOHE HE Ho HE 


6. Usethe chmod command to ensure that all files have execute 
permission: 


# chmod 755 * 


7.3 Registering Clients for Profile Sets 


After you copy CDFs and other files to the profile set directory, you can 
register RIS clients for cloning or for user-supplied file invocation during a 
full RIS installation. You do this by registering new clients to a profile set as 
well as toa RIS environment. 


In Example 7-1, you have established profile sets for client workstations 
in different departments. You are registering the client pubsos for the 
operating system in the RIS area ris0.alpha and for the profile set 
techpubs. 


Example 7-1: Sample RIS Client Profile Set Registration 


# /usr/sbin/ris 
*** RIS Utility Main Menu *** 


ADD a client 

DELETE software products 

INSTALL software products 

LIST registered clients 

MODIFY a client 

REMOVE a client 

SHOW software products in remote installation environments 
EXIT 


x*OHKBrPRPOM 
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Example 7-1: Sample RIS Client Profile Set Registration (cont.) 


Enter your choice: a 
You have chosen to add a client for remote installation services. 
The following conditions must be met to add a client: 


1. You must know the client processor’s host name 

2. The client’s host name must be in your system’s host database(s) . 

3. You must know whether the client is on an Ethernet, FDDI, or Token 
Ring network. 

4. You must know the client’s hardware Ethernet, FDDI, or Token 
Ring address if the client is registering to install operating 
system software. 

5. If the client and the server reside on different subnets, you will 
need the address of the gateway(s) that the client can use to 
communicate with the server. 


Do you want to continue? (y/n) [y]: y 
Enter the client processor’s hostname or press RETURN to quit: pubs08 
Select the remote installation environment: 
1) /var/adm/ris/ris0O.alpha 
‘Operating System Release N ( Rev nnn )’ 


‘OS Worldwide Language Support Version N ( Rev nnn ) 


2) /var/adm/ris/risl.alpha 
‘Something else in this RIS area’ 


Enter your choice or press RETURN to quit: 1 


Select one or more products for the client to install 
from /var/adm/ris/ris0O.alpha: 


Product Description 
i ‘Operating System Release N ( Rev nnn )’ 
2 ‘OS Worldwide Language Support Version N ( Rev nnn ) 


Enter one or more choices as a space-separated list 
(for example, 1 2 3) or "all" for all products [all]: 1 


You chose the following products: 
iL, ‘Operating System Release N ( Rev nnn )’ 
Is that correct? (y/n) [ly]: y 


Do you want to specify an Installation Profile Set for use 
during the installation of this client? [y/n] [n]: y 


This RIS server has the following Installation Profile Sets available: 
sys_admin engineering support techpubs accounting 

Enter a set name or press <Return> to exit set selection: techpubs 
You have selected the techpubs installation profile set. 


This set contains the following files: 
pubs_wksta 
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Example 7-1: Sample RIS Client Profile Set Registration (cont.) 


Network type: 
1) Ethernet or FDDI 
2) Token Ring 


Enter your choice: 1 


Enter the client processor's hardware network address. For 
example, 08-00-2b-02-67-e1: xXxX-xxX-XX-XX-XX-XX 


Client pubs08 has been added. 
*** RIS Utility Main Menu *** 


ADD a client 

DELETE software products 

INSTALL software products 

LIST registered clients 

MODIFY a client 

REMOVE a client 

SHOW software products in remote installation environments 
EXIT 


s 


) 
) 
) 
) 
) 
) 
) 
) 


Enter your choice: x 


# 


If the CDF in the profile set you select requires software subsets that do not 
exist in the selected RIS environment, you see the following message: 

The selected CDF, /var/adm/ris/clients/sets/techpubs/install.cdf, specifies 
software subsets that are not present in the selected RIS environment. The 


missing software subsets are: subsetnamel subsetname2 subsetname3 
subsetname4 subsetname5 subsetnameé 


Please select a different set. 
This RIS server has the following Installation Profile Sets available: 
sys_admin engineering support techpubs accounting 


Enter a set name or press <Return> to exit set selection: 


Either choose a different profile set or exit without selecting a profile set. If 
necessary, you can modify the RIS client toselect a different RIS environment 
or add the product containing the required subsets to the RIS area. 


7.4 Converting Old Configuration Description Files 


If you had existing CDFs inthe /var/adm/ris/clients/cdf directory, RIS 
must convert the old CDF s into profile sets. The first time you invokethe ris 
utility after you install this version of the operating system, the ris utility 
creates new profile set directories in the /var/adm/ris/clients/sets 
directory and copies the old CDF s into these profile sets, renaming them if 
necessary. You may see conversion messages similar to the following: 
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Converting old cdf directory to new sets directory format... 

CDF File acctng moved to set acctng and renamed install.cdf 

CDF File acctng.cdf moved to set acctngl and renamed install.cdf 
CDF File acctngl.cdf moved to set acctngl1l and renamed install.cdf 
CDF File acctng.cdf2 moved to set acctng12 and renamed install.cdf 
done 


After the old CDFs are converted to profile sets, these messages are not 
displayed again. 


7.5 Determining RIS Client Profile Set Registration 


To determine if a RIS client is registered toa profile set, examine the RIS 
database file, /var/adm/ris/clients/risdb, on theRIS server. The 
name of the profile set is specified in the fourth field; fields are separated by 
a colon. In the following sample entry in the risdb file, the client system 
portland is registered to the engineering profile set: 


portland: xx-xx-XX-XX-XX-XX:r1sS2.alpha,product_1:engineering 


7.6 Removing RIS Client Profile Set Registration 


You can remove a client from profile set registration by using the Modify 
option from the RIS Utility Main Menu. When you are prompted to specify a 
profile set for the client, enter n or press Return to register the client without 
specifying a profile set. 


7.7 Deleting Profile Sets from the RIS Server 


If a profile set is no longer needed, you can delete it by removing its 
subdirectory from the /var/adm/ris/clients/sets directory. 


Examine the RIS database file on the RIS server, 
/var/adm/ris/clients/risdb, before deleting a profile set to ensure 
that no clients are registered toit. The name of the profile set is specified 
in the fourth field; fields are separated by a colon (: ). In the following 
sample entry in the risdb file, the client vallejo is registered to the 
accounting profile set: 


vallejo: xXx-XX-XX-XX-XX-XX:ris2.alpha,product_1l:accounting 
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Troubleshooting RIS 


This chapter contains information to help you troubleshoot problems with 
your RIS system. These problems are grouped into the following categories: 


¢ RIS lock files (Section 8.1) 

¢ Client password expiration (Section 8.2) 
* Root file system mounting (Section 8.3) 
e« RIS client registration (Section 8.4) 

e« RIS server response (Section 8.5) 


8.1 RIS Lock Files 


To prevent multiple users from performing simultaneous operations on RIS 
areas, the ris utility creates two lock files in the /tmp directory, rislock 
and ris.tty.lock when you are installing or deleting software in a RIS 
area. If another user (or the same user on a different terminal) runs the ris 
utility and attempts to install or delete software from the RIS Utility Main 
Menu, they see a message similar to the following: 


The ris utility is currently locked while j_smith on /dev/ttyp3 
is installing software. Try again later. 


If the ris utility is stopped prematurely, these lock files may not be removed 
and you see this message even though no other user is using RIS. You you 
must delete the lock files from the /tmp directory. 


Caution 


Before deleting the lock files, ensure that no other user is using 
the ris utility. 


Troubleshooting RIS 8-1 


8.2 Client Password Expiration 


If the RIS server is using C2 security and the RIS password has been set 
to allow expiration, it is possible for the RIS clients to be denied service. If 
the RIS client receives a message similar to the following, the RIS password 
on the server probably has expired: 


Cannot find the name for client using bin/getname. Check with the system 
manager of your RIS server 


To fix this problem, refer to Section 3.6. 


8.3 Root File System Mounting 


RIS uses NFS tomount the root (/) file system on the client when booting the 
client from the RIS server. If you see a message on the RIS client indicating 
that the root file system cannot be mounted, usetheps -aef | grep 
mountd command line to see if the NFS mount daemon mountd is running 
on the server. If mountd is running, you see output similar to the following 

# ps -aef | grep mountd 

root 308 10.0 17:24:28 ?? 0:00.02 /usr/sbin/mountd -i -n -n 


root 3154 1053 0.0 12:52:55 ttyp3 0:00.00 grep mountd 
# 


If the mountd daemon is not running, use the SysMan Menu to restart the 
NFS daemons. If you arerunning an earlier version of the operating system, 
use the nfssetup command. Refer to the sysman(8) and nfssetup(8) 
reference pages for additional information. 


The installation media is mounted as the root file system for both CD-ROM 
and RIS installations, soit is important that the installation media is 
mounted locally on the server. Due to NFS limitations, RIS cannot provide 
client access to files that are mounted remotely from another system. The 
distribution media or extracted RIS area must be available through a local 
mount point on the RIS server. 


8.4 RIS Client Registration 
Problems with RIS client registration that are discussed in this section 
include the following topics: 
¢ Noprompt for client hardware address (Section 8.4.1) 
¢« Duplicate client hardware addresses (Section 8.4.2) 
¢ Cloned client registration (Section 8.4.3) 
¢ Client registered on multiple RIS servers (Section 8.4.4) 
¢ Client not in RIS database (Section 8.4.5) 
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8.4.1 No Prompt for Client Hardware Address 


The server requires a client’s hardware address in order to boot the client 
over the network. The ris utility prompts you for the client’s address during 
the registration process. If it does not, check the following: 


e If theRIS area is linked toa CD-ROM 
Check that the CD-ROM that is the target of the links is mounted. 


e Ifthe RIS area is serving a version of the operating system prior to 
Version 3.0 


Check that the mandatory update subsets are installed in the 

server’s RIS area for the version of the operating system that is being 
served. Install the mandatory update subsets from the /local_mnt 
/ALPHA/UPDATE directory on the distribution CD-ROM. For example, if 
the CD-ROM is installed on /mnt, install the mandatory update subsets 
from the /mnt /ALPHA/UPDATE directory. 


e |ftheRIS area is serving Version 3.0 


Check that the mandatory operating system subsets are installed into 
the RIS area. Install the mandatory subsets from the /local_mnt 
/ALPHA/BASE directory on the distribution CD-ROM. For example, if 
the CD-ROM is installed on /mnt, install the mandatory update subsets 
from the /mnt /ALPHA/BASE directory. 


¢« IftheRIS areais serving Version 4.0 and later 


Check that the OSFBASENNN subset is included in the RIS area and that 
the client is registered for that RIS area. 


8.4.2 Duplicate Client Hardware Addresses 


RIS checks to ensure that no other client has the same hardware address. 
This can happen if a client’s name has changed but has not been removed 
from the server. If a duplicate hardware address is found, a message is 
displayed like the onein the following example: 

The hardware address provided, nn-nn-nn-nn-nn-nn, has already been 

specified for another client, albany. Please check the hardware address 

to ensure it is correct. If it is correct, then you will need to 

deregister the client albany before continuing. If this client is not 

currently registered, please contact your RIS system administrator. 

If you see this message, follow the instructions provided and verify the new 
hardware address that you entered. 


e |f the hardware address you entered is not correct, reregister the new 
client with the correct hardware address. 
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e |f the hardware address you entered is correct, deregister and reregister 
the existing client (in this example, albany). 


e If the existing client is not registered, contact your RIS system 
administrator. 


8.4.3 Cloned Client Registration 


A CDF is created during a Full Installation. To use the CDF for Installation 
Cloning, the hardware configuration and the software subsets to load must 
be substantially similar. Before specifying a CDF for client Installation 
Cloning, RIS attempts to verify that the subsets specified in the CDF exist in 
the RIS area that the user has selected. If they do not match, the CDF is 
rejected. This error can occur if the version numbers of the subset do not 
match (for example, OSF BASE 400 and OSF BASE 505). 


¢ TheCDF can be used for Installation Cloning of a system that is 
registered toa different RIS area. In this first case, it is possible that the 
subsets contained in these RIS areas are different. 


¢« The version of the operating system served by the RIS area can be 
different from the version specified in the CDF. In this second case, there 
would be many missing subsets because none of the subsets specified in 
the CDF would be present in the RIS area. 


In the event that a CDF is specified that contains the name of a software 
subset that is not present in the selected RIS area, you see output similar to 
the following example: 


Enter a set name or press <Return> to exit set selection: rz26.cdf 


The selected CDF, rz26.cdf, specifies software subsets that are not 
present in the selected RIS environment. The missing software subsets are: 
OSFSERPC505 


Please select a different set. 


8.4.4 Client Registered on Multiple RIS Servers 


If the system will not boot or the system boots but is not able to mount 

the root file system, you should check to ensure that the RIS client is not 
registered for BOOTP service on multiple RIS or DMS servers. In order 

for the BOOTP protocol to work properly, it is important that the client be 
registered for BOOTP service on only one server. The client is registered for 
BOOTP service when it is registered for an operating system base product or 
when it is registered as a DMS client. 


It is possible for a RIS client to be registered to two RIS servers at the 
same time, given they are not both registered for the operating system base 
product on both servers and attempt to boot their systems using BOOTP. 
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8.4.5 Client Not in RIS Database 


If a message appears on the client’s console while you are performing a RIS 
installation that states that the client is not in the RIS database, check 
the following on the server: 


e As shown in Section 8.5, check the /var/adm/ris/clients/risdb file 
to see if the cdient’s name is entered correctly. If it is not, usethe ris 
utility to add or modify the client’s registration. 


Caution 


Do not edit the risdb file directly; usethe ris utility to add 
clients or modify client registration. 


e Ifthe /var/adm/ris/clients/risdb file contains the correct client 
name, you must determine the client’s name as recognized by the name 
servers (for example, BIND or NIS). If no name servers are in use, check 
the /etc/hosts file and the /var/adm/ris/clients/risdb file. 


- The/etc/hosts file contains the client name recognized by the 
server. 


- The/var/adm/ris/clients/risdb file contains the client name 
recognized by RIS. 


Thetwo names must match. If you are using BIND or NIS nameservers, 
use the nslookup command to find the name by which the client is 
known to the server. 


Compare the /etc/hosts fileand the /var/adm/ris/clients/risdb 
files. If one uses short name and one uses the fully qualified domain 
name, edit the /etc/hosts file to indude both the short name and the 
fully qualified domain name. This may solve the problem. 


If the /etc/hosts file uses the short name and the 
/var/adm/ris/clients/risdb file uses the fully qualified domain 
name, you may have a network configuration error. Review the 
procedures used to configure your network and name servers and correct 
them before continuing RIS installations. 


Troubleshooting RIS 8-5 


8.5 RIS Server Response 


Problems with RIS server response comprise several categories. The 
following topics are discussed in this section: 


* Servers using the bootpd daemon (Section 8.5.1) 
¢ Servers using the joind daemon (Section 8.5.2) 
e Loading an incorrect kernel file (Section 8.5.3) 


Boot failures often occur because the RIS server has invalid information. 
The risdb and bootptab files are involved in handling RIS clients, and you 
should check them in the order listed: 


e /var/adm/ris/clients/risdb 


This file is created and managed by the ris utility; it contains the 
utility’s view of the environment. Run the ris utility to show the 
configuration for the client in question. Verify that the client is registered 
and that its registration information is correct. If not, usethe ris utility 
to add or modify the client’s registration. 


« /etc/bootptab (only on servers running this operating system) 


This file is not used exclusively by RIS, so it can be edited for other 
purposes (Such as Dataless Management Services). The entry for your 
client may be corrupted. Examine the client’s bootptab entry to ensure 
that the entry agrees with both the risdb entry and the addresses and 
parameters of the equipment in your environment. The contents of the 
/etc/bootptab file are described in the boot ptab(4) and dhcptags(4) 
reference pages and in Section 5.1.3. 


Caution 


A RIS server should run either the boot pd or the joind daemon. 
A RIS server running both of these daemons is not supported, 
and results are unpredictable. 


8.5.1 Servers Using the bootpd Daemon 


A server can respond to BooTP requests from clients. If the server’s 
information is correct for the client but the server still fails to respond, 
enable BOOTP message logging on the server : 


1. Edit theserver’s /etc/inetd. conf file. 


2. Modify the line for bootps to include the —d option as a bootpd 
command argument. For example: 


bootps dgram udp wait root /usr/sbin/bootpd bootpd -d 
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3. Usethe following command to find the process IDs for the Internet 
daemons. You see output similar to the following: 


# ps x | grep -E "inetd|bootpd" 


228 ?? I 0:00.93 /usr/sbin/inetd 
243 ?? IT 0:00.91 /usr/sbin/bootpd 
9134 p2 Ss 0:00.23 grep -E inetd|bootpd 


4. Senda HupP (hangup) signal to the inetd daemon so it will reread the 
/etc/inetd.conf configuration file and kill the bootpd daemon. You 
must kill the inetd daemon before you kill the bootpd daemon. Using 
the process IDs you identified in the previous step issue the following 
kill commands: 


# kill -HUP 228 
# kill -KILL 243 


It is not necessary to restart the bootpd daemon manually; the inetd 
daemon starts it automatically. 


To track boot requests as they occur, run the tail —f command on the 
/var/adm/syslog.dated/today’s-date /daemon.1log file and boot the 
client. Many daemons other than the bootpd daemon log information to 
the daemon. log file; however, the log file shows a hardware address that 
matches the address in the /etc/bootptab file for the client. 


If the client’s boot requests are not logged, you can enable additional logging 
by editing the /etc/inetd.conf file, and add a second —d option to the 
bootpd command. Each additional instance (up to three) of the —d option 
increases reporting; the second instance enables the server to report all boot 
requests, even for client systems it does not recognize. This level of reporting 
should help you determine where in the system the request is being lost. 


If you modify the /etc/inetd.conf file, restart the inetd daemon by 
sending it a HUP signal. Example 8-1 shows a section of a daemon. 1og file. 
It shows the data logged by various system daemons, including the bootpd 
daemon when run with two —d flags set. 


Example 8-1: Sample daemon.log File 


Jul 28 14:56:36 stlouis mountd[191]: startup 

Jul 28 14:56:38 stlouis xntpd[235]: xntpd version 1.3 [1 

Jul 28 14:56:43 stlouis mold[269]: mold (V1.10) initialization complete 

Jul 28 14:56:44 stlouis evd[272]: E003-evd (V1.10) initialization complete 

Jul 28 14:56:45 stlouis internet_mom[275]: internet_mom - Initialization 
complete... 

Jul 28 14:56:45 stlouis snmp_pe[278]: M004 - snmp_pe (V1.10) initialization 
complete 


Jul 28 16:34:55 stlouis inetd[282]: /usr/sbin/bootpd: exit status 0x9 |2 
Jul 28 16:35:47 stlouis bootpd[1228]: bootpd 2.1la #0: \ |3 
Fri Feb 04 00:32:28 EST 2000 

Jul 28 16:35:47 stlouis bootpd[1228]: reading "/etc/bootptab" 
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Example 8-1: Sample daemon.log File (cont.) 


Jul 28 16:35:47 stlouis bootpd[1228]: read 3 entries from "/etc/bootptab" 
Jul 28 16:35:47 stlouis bootpd[1228]: request from hardware address \ |4 
nnnnnnnnnnnn 
Jul 28 16:36:08 stlouis bootpd[1228]: request from hardware address \ [5 
nnnnnnnnnnnn 
Jul 28 16:36:08 stlouis bootpd[1228]: found: hostl.xsamplex.com (nnnnnnnnnnnn) 
at (nn.nn.nnn.nnn) 
Jul 28 16:36:08 stlouis bootpd[1228]: file /var/adm/ris/ris0.alpha/\ 
vmunix.host1.xsamplex.com 

Jul 28 16:36:08 stlouis bootpd[1228]: vendor magic field is 0.0.0.0 
Jul 28 16:36:08 stlouis bootpd[1228]: sending RFC1048-style reply 


1] Many daemons log information to this file. 


2] Result of sending a HUP signal tothe inetd daemon and killing the 
bootpd daemon. 


3] A new bootpd daemon starts up in response to a boot request. The 
bootpd daemon reads the /etc/bootptab file as a part of its startup. 


4) A bootpd request by a system with hardware address nnnnnnnnnnnn. 
Because the system is not a client of this RIS server, its hardware 
address is not in the server’s /etc/bootptab file. 


5] A bootpd request by a system with hardware address nnnnnnnnnnnn. 
The system is a client of this RIS server. 


8.5.2 Servers Using the joind Daemon 


To serve BOOTP requests from clients, the joind daemon, which also 
services Dynamic Host Configuration Protocol (DHCP) requests, should be 
running. DHCP enables the automatic assignment of |P address to clients 
on networks from a pool of addresses. The|P address assignment and 
configuration occurs automatically whenever client systems (workstations 
and portable computers) attach to a network. The current implementation of 
DHCP is based on the J OIN product by Competitive Automation. Ensure 
that the server’s information on the client is correct, namely information 
contained in the bootptab file of the server as shown in Section 5.1.3. If 
the server still fails to respond, enable logging of bootp messages on the 
server by using the following procedure: 


1. Enter the following command to check that the joind daemon is 
servicing your bootp request: 


# ps -x | grep -E "joind" 


393 ?? I 0:05.82 /usr/sbin/joind 
26446 ttypod S + 0:00.01 grep -e joind 
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2. Enter the following command to determine the current setting of 
JOIND FLAGS: 


# remgr get JOIND.FLAGS 


3. Enter the following command to stop the joind daemon: 
# /sbin/init.d/dhcp stop 


4. Enter the following commands to restart the daemon with debugging 
turned on. Usethe JOIND FLAGS argument to indicate debugging is 
turned on. 

# remgr set JOIND FLAGS y -dx 
Where x is the level of debugging. A value from 0 to 9 is valid. 
Where y is the previously determined setting of the JOIND FLAGS. 
# /sbin/init.d dhcp start -dx 
Example 8-1 shows a section of a daemon. 1og file with the data logged 
by various system daemons, including the joind daemon. 


5. Enter the following commands to turn off debugging: 


# /sbin/init.d/dhcep stop 
# remgr set JOIND FLAGS y 
Where y is the previous determined setting of the JOIND FLAGS. 
@ determined. 
# /sbin/init.d dhcp start 


8.5.3 Loading an Incorrect Kernel File 


If the server responds but an incorrect kernel is loaded, it is possible that 
the server’s RIS area is configured incorrectly. You can observe the loading 
process by editing the /etc/inetd.conf file and restarting the I nternet 
daemon as described in the previous section. To do this, add the —d option to 
the line containing the t£tpd command: 


tftp dgram udp wait root /usr/sbin/tftpd tftpd -d /tmp /var/adm/ris 


Logging the server’s t ftp traffic shows you the file being transferred and the 
time that the transfer starts and finishes. Ensure that the proper vmunix 
file is being loaded and that the loading operations are completed correctly. 


Troubleshooting RIS 8-9 


9 


Dataless Management Services 


Dataless Management Services (DMS) lets client systems share the /usr 
file system on a centrally administered server over a network while still 
maintaining their own root (/) and /var file systems that reside on the 
DMS server. With DMS, you can save disk space by sharing the actual 
operating system software between systems. A DMS server stores the 
operating system software in a DMS area. DMS clients access the operating 
system software across the local area network (LAN) instead of from their 
local disks. Without DMS, each system maintains a copy of its operating 
system software on its own local hard disk. 


Caution 


DMS is not supported in a clusters environment. 


This chapter includes the following topics: 
¢ Defining the DMS environment (Section 9.1) 
¢ Listing the benefits of DMS (Section 9.2) 


¢ Explaining the relationship between DMS servers and clients 
(Section 9.3) 


9.1 Overview 


In a Dataless Management Services (DMS) environment, a server system 
maintains the root, /usr, and /var file systems for all client systems. The 
server maintains one copy of the root file system for each client. The /usr 
file system is exported read only and is shared by all clients registered tothe 
environment. Client systems have their own /var file system. All swapping 
and dumping is done on the client’s local disk. 


The dataless management utility (dmu) creates a root file system based on 
the software subsets installed in the DMS environment area on the server. 
This root file system is accessed by client systems over a local area network 
(LAN). DMS lets system administrators customize the root and /usr file 
systems before client systems access them. 


You must have superuser privileges to perform many of the dmu functions. 
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9.2 DMS Benefits 


The advantages of installing DMS include the following: 


e Less disk space is required on client systems. By sharing the /usr area, 
you eliminate the need for disk space to hold a separate /usr area for 
each client. For Alpha systems, you can save more than 425 megabytes 
(Mb) for each client. 


¢ Installation and setup of servers and clients are done by automated 
scripts, thereby simplifying the task of the server system administrator. 
Maintenance of the DMS areas is similarly straightforward. 


¢ Because the DMS files reside on the server, the server’s system 
administrator can perform most system management tasks. The 
involvement of individual users with the complexities of system 
management is reduced. 


9.3 Relationship Between DMS Servers and Clients 


The DMS utility, dmu, manages the sharing of installed operating system 
software between servers and clients in a LAN. In addition to the server’s 
normal disk area, one or more disk partitions are reserved as the DMS area, 
made up of one or more product environments and client areas. This section 
includes the following topics: 


¢ Describing the DMS server (Section 9.3.1) 

¢« Explaining the environment portion of a DMS area (Section 9.3.2) 
¢ Explaining the cient portion of a DMS area (Section 9.3.3) 

¢ Describing DMS client characteristics (Section 9.3.4) 


9.3.1 DMS Server 


The DMS server maintains multiple copies of the root area, one for 

each client. Each copy isin a client root directory in the DMS area and 

is customized for the client in order to provide for differences between 
hardware platforms or environmental requirements. Each of the client root 
directories is private; this means that there is a directory for each client so 
that no conflict or confusion exists between clients. The server’s DMS root 
and /usr areas are made available to clients by means of the Network File 
System (NFS). For more information about the NFS used by the operating 
system, refer to the Network Administration guide. 


Beyond verifying clients’ identities, vectoring their boot requests, and 
providing their system disk space, the server does not interact directly with 
the clients. The server can support local timesharing users and need not 
be dedicated to DMS. 
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A DMS dient’s system disk space (root and /usr areas) is physically 
connected to the server instead of to the client. The client accesses that disk 
area through a LAN connection with the server. Each DMS client is booted 
across the network from its private root area on the server. Once booted, 
the client continues to use its root files and /usr files from the server’s 

DMS area. These files appear to the client as if they were on local disks, as 
shown in Figure 9-1. 


Figure 9-1: File Sharing Between the DMS Server and Client 
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As indicated in Figure 9-1, clients must have local disks. In addition to local 
disks, clients can import file systems from any other computer to which they 
have network access. Clients use swap and dump space on their local disks. 


9.3.2 Environment Portion of DMS Area 


One or more DMS environments can reside in a partition. If you want to 
prevent the dmu utility from putting all DMS environments in the same disk 
partition, indicate a unique mount point for each DMS environment. The 
DMS environment disk space requirements should be calculated using the 
worksheets in Appendix B. Then the mount point of . /dmsn.alpha should 
be added to the /etc/fstab file 


Each DMS environment contains a customized directory and file system, 
consisting of root, /usr, and /var. The dmu utility copies the root area to 
the client area when a client is added to the dataless environment. 


Figure 9-2 shows the /var/adm/dms portion of a DMS area, it contains 
two DMS environments, dmsO.alpha and dms1.alpha. Each DMS 
environment contains a root and /usr file system. The root file system is 
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copied to each client system. The /usr file system is read only and is shared 
among all client systems registered to the environment. 


Figure 9-2: Environment Portion of DMS Area 
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The root file system contains copies of the kernel, . vmunix, vmunix and 
other primary system files. These primary files can bein either new form 
(files supplied in the operating system distribution kit and prefixed with 
.new..) or in prototype form (files prefixed with .proto. .). 


Do not customize the .new.. version of a file. 


The .proto.. files have special significance for DMS environments. By 
modifying the .proto.. files, you can customize the DMS server to meet 
specific needs. You can use these customized .proto.. files when you 
configure the DMS client environments. You also can modify standard files 
such as /etc/hosts and /etc/fstab so that DMS clients do not have 
to modify them. 


The /usr file system contains common files that can be used without being 
tailored by clients registered to the DMS environment. 


DMS environments can be created with different combinations of products to 
allow servers to provide diversified service based on client’s software product 
needs. For example, you could havea DMS environment with only the base 
operating system. Another DMS environment could have the base operating 
system plus any number of additional products (such as DE CLadebug or 
DEC Fortran) installed. Multiple environment areas can be established 

in separate partitions to support a variety of environments, or to improve 
performance, or to support more clients than allowed by the disk space 
available in the /var/adm/dms directory. 


The server does not use any of the DMS area. System administrators can 
access the DMS area as required for maintenance and for installation or 
removal of layered products, but the area is not used by the server itself. 
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9.3.3 Client Portion of DMS Area 


A DMS dient area for individual DMS client systems also resides in a 
DMS area. Figure 9-3 shows a DMS client area named /clients. Place 
this DMS client area in its own partition after you calculate the required 
size with the worksheets in Appendix B. Next, add the mount point of the 
/clients DMS client area tothe /etc/fstab file. 


Figure 9-3: DMS Client Area 
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Multiple copies of the root file system reside in the client area, one for 

each client, tailored from the generic root file system. Each client builds a 
customized kernel, which resides in the client’s root area if the client has 

a partial or full build environment. This customized kernel supports the 
client’s actual system configuration, including central processor, system 
memory, and peripheral devices. Figure 9-3 shows two client root areas, 
named ClientA and ClientB. Each client sees its private root area and the 
shared /usr area from the /var/adm/dms environment as local, although 
these areas are actually on the DMS server and are accessed through NFS. 
Figure 9-4 shows how clients share /usr and have their own root file system. 


You can establish multiple client areas but they must reside in different 
partitions. 


9.3.4 Characteristics of DMS Clients 


Clients do not have access to the entire DMS area. Each DMS client has 
access to the root area assigned to it on the server. 


Common system files residing in the /usr area are shared among all the 
clients registered to that particular /var/adm/dms environment. Mounted 
with read-only access for the clients, this shared area is protected from 
erroneous client activity. Figure 9-4 illustrates this concept. 
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Figure 9-4: Client Views of the DMS Area 
Server 
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In Figure 9-4, the small boxes represent what the clients think they see; 
the arrows show how the real disk areas on the server are mounted by the 
client to produce this view. 


Clients can be timesharing systems or workstations. Because each client’s 
root area is tailored specifically to the client’s needs and would contain 

the software the client can run, there is no interference between clients 
attempting to use identical resources that could, for example, have licensing 
restrictions based on the number of concurrent users. 
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Preparing DMS Servers and Clients 


This chapter describes how to get DMS servers and clients ready torunina 
dataless environment. Perform the following steps to prepare DMS servers 
and clients: 


po oN au WN 


Meet requirements for DMS servers. (Section 10.1) 

Meet requirements for DMS clients. (Section 10.2) 

Allocate disk partitions for DMS. (Section 10.3) 

Set up a local area network. (LAN). (Section 10.4) 

Set up a Network File System. (NFS). (Section 10.5) 

Plan and calculate DMS disk space requirements. (Section 10.6) 

Install the operating system software on the DMS server. (Section 10.7) 
Register DMS clients. (Section 10.8) 

Understand DMS security issues. (Section 10.9) 


10.1 Requirements for DMS Servers 


Setting up a dataless environment requires that the following conditions be 
met for DMS servers: 


A DMS server must have Version 3.0 or higher of the operating system 
installed to serve client systems with the current version of the operating 
system. The server can be any Alpha-based processor, with the exception 
of those noted in Section 1.2. A single server can serve both RIS and 
DMS clients, but a client cannot be registered to both RIS and DMS at 
the same time. DMS servers can serve only clients running Version 3.0 
or higher of the operating system. 


The DMS server must have the following software subsets installed: 
- Additional Networking Services (OSFINET) 
- Dataless Management Services (OSFDMS) 


The DMS server must have the OSF-SVR or UNIX-SERVER Product 
Authorization Key (PAK) loaded and registered. The OSF-SVR or 
UNIX-SERVER license allows an Alpha-based system to be a server. 
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Refer to Software License Managenent for more information about 
software licensing. 


The DMS server must be able to install software into the DMS area: 


- TheDMS server can have a CD-ROM drive to install software 
subsets for one or more specific products from the CD-ROM tothe 
DMS area on the server. 


- TheDMS server can usea Network File System (NFS) mount point 
toinstall software from a Remote Installation Services (RIS) area or 
an operating system distribution CD-ROM from another processor. 
See Section 4.5 for more information about using an NFS mounted 
RIS area. 


The DMS server must have at least one separate disk partition where the 
DMS environment and client areas reside. The root would not be large 
enough for many client areas and var likely would fill up after one 
environment was added. Smaller disks may not hold an entire DMS area. 


NFS must beset up on the DMS server. 


The DMS server and all DMS clients must be connected to an Ethernet 
or FDDI local area network (LAN). 


10.2 Requirements for DMS Clients 
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Setting up a dataless environment requires that the following conditions be 
met for DMS clients: 


DMS clients must havea disk drive large enough to accommodate dump 
and swap file systems (approximately 200 Mb). 


DMS clients must be registered with the server in one of the following 
ways: 


- Register the DMS client through either the NIS naming service using 
Network Information Service (NIS) or the BIND naming 
service using BIND Configuration Application. 


- Create an entry for the DMS client in the server’s /etc/hosts file 
either by using Network Configuration Application or by 
manual entry using a text editor. 
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« DMS clients must be capable of booting over Ethernet or FDDI using the 
bootp and tftp protocols. This is the same requirement to be able to 
install the operating system froma RIS server. Most Alpha workstations 
and deskside servers have this capability, but most data center servers 
would not be configured as DMS clients. Consult your system’s hardware 
documentation to determine whether it supports bootp and tftp over 
Ethernet or FDDI. 


¢« Theclient must not be registered on another RIS or DMS server. 


10.3 Allocating Disk Partitions on the DMS Server 


The DMS server must have at least one separate disk partition to contain 
the DMS environment and client areas. Otherwise, the root file system is not 
large enough for many client areas and the var file system would fill up 
after one environment was added. Deciding how to allocate disk partitions 
is critical to the performance of dataless management. Consider the 
following factors when allocating disk partitions for the DMS environment 
(/var/adm/dms/dmsN .alpha) and client (/clients) area: 


¢ Thenumber of physical blocks available compared to the number of 
blocks required by the environments you expect to create on the disk. 


¢ Spreading environments with large numbers of registered clients among 
different disks to reduce disk contention. 


¢ Protecting against disk failures by using the Logical Storage M anager 
(LSM). 


e« Using the Advanced File System (AdvFS) on certain disks for 
faster system recovery. Refer to the AdvFS Administration, Systen 
Configuration and Tuning, and Systen Administration manuals and 
the advfs(4) reference page for more information about the Advanced 
File System. 


Refer to the Systen Administration guide for more information about disk 
partitioning. 


10.4 Setting Up a Local Area Network (LAN) 
You must connect the DMS server and all of the client processors to an 


Ethernet or FDDI LAN. For instructions on setting up a LAN, refer tothe 
Network Administration guide. 


10.5 Setting Up a Network File System 


The Network File System (NFS) must be set up before you install DMS. For 
instructions on setting up NFS, refer to the Network Administration guide. 
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After you install NFS, ensure the portmap, mountd, nfsd, and nfsiod 
daemons are running by entering the following command: 


# pS ax grep -E "portmap|mountd|nfsd|nfsiod" 
P 


If these daemons are not all running, start the inoperative ones. Refer to the 
appropriate reference pages for information about starting these daemons. 
For example, enter the following command to display the port map(8) 
reference page: 


# Man portmap 


10.6 Planning Disk Space for DMS 


You must calculate the amount of disk space required to ensure that you 
have enough space in the DMS areas in which the dmu utility will be created. 
DMS clients’ system disk space is located on the server in a DMS area. See 
Section 9.3.2 for a description of the DMS area’s contents. A server can have 
multiple DMS areas in which some of the files (for example the contents 

of the /usr area) are duplicated. This necessary duplication imposes 
additional space requirements on the server. 


This section discusses the following topics: 

¢« Disk space required for DMS environments (Section 10.6.1) 
e Estimating disk space for DMS clients (Section 10.6.2) 

e The types of kernel builds (Section 10.6.3) 


Throughout this guide, the server’s environment file systems are designated 
as /var/adm/dms/dmsN .alpha and /clients/hostname where 
hostname is the name of the dient. The root areas are designated dmsN 
.alpha where the letter nrepresents the number assigned tothe specific file 
system or common root area when it is installed. The client’s private portion 
of the common root area is designated /clients/hostname. 


Disk space is required on the server for each DMS server area file system. 
The following sections provide guidelines for estimating the disk space 
required by the DMS area. 


Appendix B contains worksheets to help you calculate your space 
requirements. 
10.6.1 Disk Space Required for DMS Environments 


Each dmsN .alpha environment must have the following software subsets 
installed: 


¢ Additional Networking Services (OSFINET) 
¢« Dataless Management Services (OSFDMS) 
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Each dmsN .alpha environment also can contain additional software for the 
clients registered to access that environment. Section 11.2 describes how to 
install software in DMS environments. 


Reserve the following space in addition to space needed for the mandatory 
subsets and the subsets required by DMS: 


¢« Enough space for any layered products that you plan to install at any 
time in the future 


¢« An additional 10 percent of the required disk space to allow for file 
system administration tasks and file system information 


Appendix B contains worksheets for calculating the amount of space you 
need for a single DMS environment. Refer to the first worksheet as you read 
the calculation illustrated in Table 10-1. 


Caution 


Subset sizes in this example are for illustration only. The actual 
sizes for standard operating system subsets are listed in the 
Release Notes. Subset size information for layered products is 
included in the product installation documentation. 


To determine the names of the subsets you want to install, refer 
to the descriptions listed in the Installation Guide. 


Assume that you want to install all of the mandatory and optional subsets 
plus one layered product. You need at least one DMS environment, 
/var/adm/dms/dmsN .alpha. 


For example, you refer to the Release Notes and determine the estimated 
subset sizes in Table 10-1: 


Table 10-1: Estimated Subset Sizes for DMS 


Subsets Size in Mb 
Mandatory subsets 250 
All optional subsets 400 
One layered product subset 50 
SUBTOTAL 700 
+10 percent for overhead 70 
TOTAL 770 


The subset sizes add up to 700 Mb. Allowing another 10 percent of this 
space (70 Mb) for file system administration and information, you arrive at 
a total size of 770 Mb for the /var/adm/dms/dmsN .alpha environment. 
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10.6.2 


10.6.3 


Reserve additional space for any other software products you plan to install 
later. These products’ space requirements must be factored into the 10 
percent overhead allocation. 


Estimating Disk Space for Clients 


You must reserve disk space in the /clients file system on the server for 
clients’ root areas. The amount of disk space required depends upon the type 
of kernel build you choose for the client. 


Refer to the second DMS worksheet in Appendix B to calculate the amount 
of space needed for a /clients area. 


Considering Types of Kernel Builds 


When you are adding clients toa DMS environment, you have the option 

to choose: no build, full build, or partial build kernel support. When 
determining the amount of space required by a client, you must keep in mind 
the type of build support you choose for the client. 


Clients’ volatile files, such as thosein the /tmp, /var/spool, /var/sys, 
and /var/adm directories are located in the individual client’s root area. 
The client’s root area requires a minimum of 40 Mb of disk space. Usethe 
following guidelines for estimating disk space requirements, in addition to 
the 30 Mb minimum required by the client: 


¢ No build support 


This type of kernel build is not recommended. Providing no build area 
means that the clients cannot build kernels and must run the Generic 
DATALESS kernel supplied by the system administrator. No build 
support is available only when the server and client are on the same 
version of the operating system. Additionally, no build support kernel 
build type does not allow the client to build a customized kernel. If you 
choose no build support, you do not need to allow for extra disk space 
other than the required minimum 30 Mb. 


e Full build support 


A full build area creates an entire /sys area for the client and consumes 
the most disk space. You should select this option if the client modifies 
kernel objects and performs kernel builds. If you choose a full build, 
allow an additional 100 Mb for each client’s root area. 


¢ Partial build support - Default for clients running Version 3.2C or higher 
of the operating system 


A partial build area creates a build area that contains only configuration 
data. All kernel objects are obtained from the server. You should select 
this type of build if the client performs kernel builds but does not modify 
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kernel objects. If you choose a partial build, allow an additional 15 Mb 
for each client’s root area. 


The space required by individual clients will not be the same, but you can 
add all the needed spaces together to arrive at the total requirement for the 
/clients area. You also must remember to reserve additional space for 
clients that add files to their root areas. 


10.7 Installing the Operating System on the DMS Server 


The Installation Guide describes how to install the operating system and 
describes the standard operating system software subsets. Subset sizes are 
listed in the Release Notes. 


The following optional software subsets must be installed on the server to 
set up a DMS environment: 


¢ Additional Networking Services (OSFINET) 
« Dataless Management Services (OSFDMS) 


To install these software subsets, you can follow either one of these 
procedures: 


¢ Performa Full Installation and choose the OSFINET and OSFDMS subsets 
along with any other subsets you choose to install. 


¢ Perform a Full Installation with mandatory subsets only. After the 
installation is complete, use the SysMan Menu to install the subsets 
listed previously and any additional software subsets. 


For information about using the SysMan Menu toload software subsets, 
refer to the Installation Guideor the sysman(8) reference page. 


10.8 Registering DMS Clients 


Before you can use DMS toservea client, you must register the client with a 
network naming service and with the DMS server. You must perform the 
following tasks to prepare to register clients: 


Obtain information about each client (Section 10.8.1) 


Fill out a copy of the DMS Client Setup Worksheet for each client 
(Appendix B) 


3. Register each client’s host name and IP (Internet Protocol) address 
with the appropriate naming service, either by using the NIS or BIND 
Configuration Application or by placing an entry for the client in 
the server's /etc/hosts file (Section 10.8.2) 
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10.8.1 Obtaining DMS Client Information 


You need to know the following information about each processor you plan 
toadd as a client toa /var/adm/dms/dmsN .alpha environment and to 
register the client with the appropriate naming service: 

¢ The host name 


Only lowercase letters (a-z), numerals (0-9), and the period (.) and 
dash (-) characters are permitted in host names, which must begin 
with a letter. 


« TheDMS environment and client areas to which you want to register 
the client 


¢« Theclient’s network interface type, subnet mask and gateway address 
for this network interface 


The gateway address is required when the server and client are on 
different networks. 


Refer to the Network Administration guide for information about 
network interfaces, subnet masks and route for network. 


¢ Theclient’s Ethernet or FDDI hardware address 


Refer tothe Network Programmer’s Guide or Section 6.2 for information 
about how to obtain hardware addresses. 


e« The swap device and partition and swap device drive type (swapping 
is done on the client’s local disk) 


Refer to the Installation Guide — Advanced Topics for guidelines on 
planning swap space on the client’s local disk. However, keep in mind 
that because the /usr file system is not on the client’s local disk, you 
have much more space on the client to allocate for swap space. 


¢ Thetype of kernel build to be supported (full, partial, or none). Refer 
to Section 10.6.3 for a description of the types of kernel build support 
for the client. 


10.8.2 Registering Clients Host Names and IP Addresses 


If the host system is served by any of the following naming services, check 
with your site administrator to be sure that your clients are registered with 
the appropriate naming service servers: 


« Theserver’s /etc/hosts file 
¢« Berkeley Internet Name Domain (BIND) 
¢« Network Information Services (NIS), formerly called Yellow Pages (YP) 


By using the Network Configuration Application, you can place each client 
processor’s host name and IP (Internet Protocol) address inthe /etc/hosts 
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file when you initially set up your LAN. The Network Configuration 
Application is described in the Network Administration guide. 


You also can place the host name and IP address in the /etc/hosts file by 
using a text editor such as vi. The host name and |P address for each client 
processor must be unique. 


Refer to the Network Administration guide for information about setting up 
NIS and the BIND Configuration Application. 


10.9 Considering Security Issues 
C2 security may be installed on the server and the clients. However, DMS 


uses the bootp protocol, which is not a secure protocol. Therefore, your 
dataless environments may not be secure. 
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11 


Setting Up a DMS Environment 


This chapter describes how to use the dmu utility to add software toa DMS 
environment and how to configure the environment. The following topics 
are discussed: 


Ensuring version compatibility between DMS servers and clients 
(Section 11.1) 


Installing software into a new DMS area (Section 11.2) 

Adding software into an existing DMS environment (Section 11.3) 
Customizing and configuring a DMS environment (Section 11.4) 
Installing WLS support in DMS (Section 11.5) 


11.1 Ensuring DMS Server and Client Compatibility 


If you are installing this version of the operating system into a DMS 
environment and the DMS server is running a previous version of the 
operating system, you must perform the following procedure: 


1. 


Log into the DMS server as root or use the su command to gain 
superuser privileges. 


Insert the Operating System Volume 1 CD-ROM into the drive, then 
mount the CD-ROM. 


e If your server is running the current version of the operating system, 
use a command similar to the following example: 


# mount -rd /dev/disk/cdrom0c /mnt 


This example mounts a CD-ROM drive that is device 0 on the mount 
point /mnt. 


e If your server is running an earlier version of the operating system, 
use a command similar to the following example: 
# mount -rd /dev/rz4c /mnt 


This example uses a CD-ROM drive that is unit 4 and specifies 
/mnt as the mount point. 


If your driveis a different unit, substitute the correct device name. The 
mount point does not have to be /mnt. 


Refer to Section 1.3 if you do not know the CD-ROM drive's unit number. 
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3. Usethe mount command to update DMS on the server, as in the 
following example (using /mnt as the mount point): 


# /mnt/isl/utilupdate -d -m /mnt 


e In this example, the -d copies several files from the distribution 
CD to the server’s /usr/sbin directory. This ensures DMU 
compatibility with the operating system. 


¢ The-m directory is the mount point of the distribution media. In 
this example, directory is /mnt, and is a required parameter. 

This procedure copies files in the /usr/sbin directory to files with 

a *.pre-V5.0A suffix, for example: /usr/sbin/setld is copied to 

/usr/sbin/setld.pre-V5.0A. 


When the utilupdate script completes, this RIS server can serve the 
current version of the operating system toa DMU client. Refer to Appendix C 
for information about the utilupdate utility. 


If the utility finds existing * .pre-v operating system files on your system, 
no copies are made. If the server is already running the current version of 
the operating system (or higher), a confirmation is displayed and no copies 
are made. 


11.2 Installing Software in a New DMS Environment 


You must install and configure all the software you plan to useina 

DMS environment before you can add clients to share the environment. 
Section 11.3 describes how to install additional software into an existing 
DMS environment. 


Follow these steps to install software into a new dmsN .alpha environment. 
Repeat the installation procedures for each dmsN .alpha environment you 
plan to set up. 

1. Login as root or use the su command to gain superuser privileges. 


2. Insert the Operating Systen Volume 1 CD-ROM into the drive, then 
mount the CD-ROM. 


e If your server is running the current version of the operating system, 
use a command similar to the following example: 


# mount -rd /dev/disk/cdrom0c /mnt 


This example mounts a CD-ROM drive that is device 0 on the mount 
point /mnt. 


e If your server is running an earlier version of the operating system, 
use a command similar to the following example: 


# mount -rd /dev/rz4c /mnt 
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This example uses a CD-ROM drive that is unit 4 and specifies 
/mnt as the mount point. 


If your driveis a different unit, substitute the correct device name. The 
mount point does not have to be /mnt. 


Refer to Section 1.3 if you do not know the CD-ROM drive's unit number. 


Note 


You can use a Network File System (NFS) mount point to 
install software from a Remote Installation Services (RIS) 
area or Operating System Volume 1 CD-ROM from another 
processor. Refer to Section 4.5 for more information about 
using an NFS mounted RIS area. 


Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu: 


*** DMU Main Menu *** 
Choices without key letters are not available. 


ADD a client 
CONFIGURE software environments 
DELETE software environments 


) 

) 

) 

1) INSTALL software environments 
) LIST registered clients 
) 
) 
) 
) 


MODIFY a client 

REMOVE a client 

SHOW software environments 
EXIT 


x 


Enter your choice: 


If this is the first time you have accessed dmu, there are no DMS 
software environments installed. The only option you have is to install 
software into an environment or to exit from the utility. 


Enter i toselect INSTALL software environments. You see the 
DMS Software Installation Menu: 


DMU Software Installation Menu: 


Install software into a new area 

Add software to an existing area 

Perform configuration phase on an existing area 
Return to previous menu 


BwWNoH 


Enter your choice: 
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5. Enter 1toselect Install software into a new area. You see 
the following prompt: 


You have chosen to establish a new remote dataless environment. 


Enter the device special file name or the path of the directory where 
the software is located (for example, /mnt/ALPHA/BASE) : 


6. Enter the software location, for example: /mnt /ALPHA/BASE. 


¢ |f your distribution media is CD-ROM mounted on /mnt, the 
directory where the software is located is /mnt /ALPHA/BASE. 


¢« Enter a device specific file name only for magnetic tape media. 


The dmu utility lists the mandatory and optional software subsets you 
can install. 


The following subsets must be installed in the DMS environment: 
¢ Additional Networking Services 
« Dataless Management Services 


7. Select the subsets that you want to extract; the dmu utility displays your 
list for confirmation. For example: 
The following subsets are mandatory and will be installed 


automatically unless you choose to exit without installing 
any subsets: 


{mandatory subset list} 


Optional subsets are listed below. There may be more optional 
subsets than can be presented on a single screen. If this is 

the case, you can choose subsets screen by screen, or all at 
once on the last screen. All of the choices you make will be 
collected for your confirmation before any subsets are installed. 


{optional subset list} 


Or you may choose one of the following options: 


94) ALL mandatory and all optional subsets 
95) MANDATORY subsets only 

96) CANCEL selections and redisplay menus 
97) EXIT without extracting any subsets 


Enter your choices or press RETURN to redisplay menus. 
Choices (for example, 1 2 4-6): 94 


The following subsets will be loaded: 
{selected subset list - all mandatory & optional in this example} 


Are these the subsets that should be loaded (y/n) ? 
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If you enter y, the dmu utility loads the subsets. If you enter n, the list 
of subsets is displayed again and you can restart your selection process. 


The new DMS environment is located in the /usr/v ar/dms/dmsN.alpha 
directory. 


If there is not enough disk space to perform the installation, you see a 
prompt similar to the following: 


fitset: 

file system /usr needs 74683 Kbytes more to install the software specified. 
setld: 

There is not enough file system space to install the mandatory subsets. 
setld failed. 


Error(s) have occurred during subset load. The subset(s) that failed 
are listed above and have not been installed into the environment. 
Possible causes for failure include subset dependencies that have 
not been met or the lack of disk space. 


You will now be asked if you wish to keep this environment. 

If you elect to keep the environment, you may install the subsets that failed 
by choosing INSTALL from the DMS main menu and select an existing environment. 
If you elect not to keep the environment, it will be completely removed. 


Keep this environment (y/n) ly]: 
¢ If you want to keep the new DMU environment, enter y. 


e If not, enter n, and the dmu utility terminates the installation and 
returns tothe DMU Main Menu. Either resize your disk partitions or 
select fewer optional software subsets. 


After the installation of software subsets is complete, the dmu utility displays 
the name of the new DMS environment. If this is the first DMS environment, 
it automatically is named dmsO.alpha. Subsequent DMS environments are 
numbered sequentially: the next environment is named dms1.alpha, the 
one after that is named dms2.alpha, and soon. 


If you delete an environment, for example dms4 .alpha, the next time you 
install a DMS environment, the dmu utility reuses the number 4 toname the 
environment. The utility fills the holes left in the numbering sequence by 
environments that have been deleted. 


After you install software into the DMS environments, you must configure 
and build the kernel for that environment. Refer to Section 11.4.2 for 
instructions on how to begin the kernel configuration phase. However, if you 
want to add additional software to the environment before configuring the 
kernel, refer to Section 11.3. 
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11.3 Adding Software to an Existing DMS Environment 
Perform the following steps to add software toan existing DMS environment: 
1. Loginas root toeach DMS client registered to the DMS environment 


or use the su command to gain superuser privileges. 
2. Usethe shutdown command to shut down the DMS dient. 


Caution 


If DMS clients that mount the usr area of the target 
/var/adm/dms/dmsN .alpha area are running when you 
install an additional software product, their usr area may 
change unpredictably and cause destruction of software or 
data or both. 


Repeat this step for each DMS client registered tothe DMS environment 
where you are adding software. 


3. Login as root tothe DMS server or use the su command to gain 
superuser privileges. 


4. Mount the CD-ROM that contains the software you want to install as 
shown in Section 11.2, or mount the file system area that contains the 
software kits. 


5. Enter /usr/sbin/dmu to start the dmu utility. You seethe DMS Main 
Menu: 


*** DMU Main Menu *** 


Choices without key letters are not available. 


SHOW software environments 
EXIT 


n 


a) ADD a client 
c) CONFIGURE software environments 
d) DELETE software environments 
1) INSTALL software environments 
1) LIST registered clients 
m) MODIFY a client 
r) REMOVE a client 
) 
) 


x 


Enter your choice: 
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Enter i toselect INSTALL software environments. You see the 
DMS Software Installation Menu: 


DMU Software Installation Menu: 


Install software into a new area 

Add software to an existing area 

Perform configuration phase on an existing area 
Return to previous menu 


BWdY Pe 


Enter your choice: 


Enter 2 toselect Add software to an existing area. You seea 
prompt similar to the following: 


You have chosen to add a product to an existing environment. 


The existing environment is /var/adm/dms/dms0.alpha. 


Note 


In the previous example, only one environment, dms0.alpha, 
exists. If you have more than one DMS environment, you see 
a prompt similar to the following: 


Select the remote dataless environment: 


1) /var/adm/dms/dms0.alpha 
‘Tru64 UNIX VAAA Operating System (Rev nnn)’ 


2) /var/adm/dms/dms1.alpha 
‘Tru64 UNIX VBBB Operating System (Rev nnn)’ 


Enter your choice: 


Enter the number corresponding to the DMS environment 
where you want to install the software. 


You see the following prompt: 


Enter the device special file name or the path of the directory where 
the software is located (for example, /mnt/ALPHA/BASE) : 


Enter the software location, for example: /mnt /ALPHA/BASE. 


¢ If your distribution media is CD-ROM mounted on /mnt, the 
directory where the software is located is /mnt /ALPHA/BASE. 


¢ Enter a device specific file name only for magnetic tape media. 


The dmu utility lists the mandatory and optional software subsets you 
can install. 
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9. Select the subsets that you want to extract; the dmu utility displays your 
list for confirmation. For example: 


The following subsets are mandatory and will be installed 
automatically unless you choose to exit without installing 
any subsets: 


{mandatory subset list} 


Optional subsets are listed below. There may be more optional 
subsets than can be presented on a single screen. If this is 

the case, you can choose subsets screen by screen, or all at 
once on the last screen. All of the choices you make will be 
collected for your confirmation before any subsets are installed. 


foptional subset list} 


Or you may choose one of the following options: 

ALL mandatory and all optional subsets 
MANDATORY subsets only 

CANCEL selections and redisplay menus 

EXIT without extracting any subsets 

Enter your choices or press RETURN to redisplay menus. 


Choices (for example, 1 2 4-6): 24 


The following subsets will be loaded: 
{selected subset list - all mandatory & optional in this example} 


Are these the subsets that should be loaded (y/n) ? 


If you enter y, the dmu utility loads the subsets. If you enter n, the list 
of subsets is displayed again and you can restart your selection process. 


The dmu utility installs the software subsets that you selected. This 
can take an hour or more 


After the dmu utility installs the software, you seethe DMU Main Menu. 


10. Follow the instructions in Section 12.4 to delete the DMS clients 
registered to the DMS area where you installed the software. 


11. Follow the instructions in Section 11.4.2 to reconfigure the DMS area 
where you installed the software. 


12. Follow the instructions in Section 12.2 to add the DMS clients deleted 
in the previous step to the DMS area where you installed the software. 
When you remove and add clients to the reconfigured environment, 
customized information in the root (/) directory is lost. 
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11.4 Configuring DMS Environments 


After you install software into a new or existing DMS environment, you 
must configure the environment. Configuring the environment includes the 
following steps: 


1. Customizing the .proto.. system files (Section 11.4.1). This step is 
optional; you do not have to customize these files for the environment. 
This step is performed outside of the dmu utility. 


2. Building the environment’s kernel (Section 11.4.2). This step is 
mandatory and is performed through the CONFIGURE software 
environments option of the DMU Main Menu. 


11.4.1 Customizing /etc/.proto..* Files 


If you already have configured the DMS environment and later decide to 
modify .proto.. files, you must delete the files created by the configuration 
process. F ollow these steps to modify the fstab filetoincludea server name: 


1. Logintothe DMS server as root or use the su command to gain 
superuser privileges. 


2. DefinetheDMS_ROOT environment variable to point to the affected DMS 
area, for example: 


# DMS ROOT=/var/adm/dms/dmsN.alpha/root 
3. Deletethe SDMS_ROOT/hosts file 
Modify the $DMS_ROOT/.proto. -hosts file 


5. Usethe dmu utility to configure the DMS area as described in 
Section 11.4.2. 


Modify the .proto. . files to customize each environment for the clients 
that you will add toa DMS environment. If you do this customization 
before you configure and build the kernel and before you add clients to the 
DMS environment, you reduce the amount of customization required at 
each client. 


You may want to modify several of the .proto.. files located in 

the DMS environment /var/adm/dms/dmsN .alpha in the /etc, 
/bin, /var/adm/X11, and root directories. As an example, the 
/etc/.proto..hosts file is a file that you could modify in advance 
Table 11-1 lists the .proto.. filesin the /etc directory that you can 
customize. 
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Table 11-1: List of /etc/.proto.* Files 


-proto. . TIMEZONE -proto..lprsetup.dat 
.proto..acucap .proto..magic 
-proto..autopush .proto..motd 

-proto. .binlog.conf .proto. .networks 
.proto..conf -proto. .ntp.conf 
-proto..ddr.db -proto..passwd 
-proto..ddr.dbase -proto..phones 
-proto..dhcptab -proto..profile 
.proto. .dvrdevtab -proto..proto.disktab 
.proto..exports .proto..protocols 
-proto..fstab -proto..rce.config 
-proto..ftpusers .proto..remote 
.proto..gen_ databases -proto..rpc 
-proto..gettydefs -proto..securettys 
.proto..group .proto..services 
.proto..hosts -proto..shells 
.proto..hosts.equiv -proto..slhosts 
-proto..ifaccess.conf .proto..stresetup.conf 
-proto..inet.local -proto..svc.conft 
-proto..inetd.conf -proto..sysconfigtab 
-proto..inittab -proto..syslog.conf 


For example, the /etc/.proto..hosts file contains no host names. Edit 
this file toinclude the network addresses, names, and aliases of well-known 
systems in your environment. Enter server information so that you do not 
have to enter this information for each client when setting up network 
services. Refer to the host s(4) reference page for information about the 
layout of this file. 


You should list commonly mounted NFS file systems, as well as the /proc 
file system if it will be used by cients. When you add NFS file systems 

to the etc/.proto..fstab file, you also should add the hosts to the 
etc/.proto..hosts file If the NFS mount points are in the client root 
partition, make the directory mount points in the DMS root area as well. If 
they arein the shared usr directory structure, make the directory mount 
points in the DMS usr directory area. 
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After you modify the .proto.. filesin the DMS environment, configure the 
DMS environment by following the steps in Section 11.4.2. 


11.4.2 Configuring the DMS Environment 


After you modify the .proto.. files, use the following procedures to 
configure the DMS environment: 


1. 


Log into the DMS server as root or use the su command to gain 
superuser privileges. 


Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu: 


*** DMU Main Menu *** 


ADD a client 

CONFIGURE software environments 
DELETE software environments 
INSTALL software environments 
LIST registered clients 

MODIFY a client 

REMOVE a client 

SHOW software environments 

EXIT 


H- OQ 


~ OD 


Enter your choice: 


Enter c toSelect CONFIGURE software environments. You seea 
prompt similar tothe following example, which contains two DMS areas: 


You have chosen to configure an existing dataless 
environment. 


Select the remote dataless environment: 


1) /var/adm/dms/dms0.alpha 
‘Tru6é4 UNIX VAAA Operating System (Rev nnn)’ 


2) /var/adm/dms/dmsl1.alpha 
‘Tru6é4 UNIX VBBB Operating System (Rev nnn)’ 


Enter your choice: 


Enter the number corresponding with the DMS environment you want 
to configure. You see the following prompt: 


There are several files prefixed by .proto.. within the 
environment area that should be modified before performing 

a configuration of the area. Performing this customization 

of the environment before you register clients will reduce the 
amount of customization required at each client. 
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You may now choose to continue with the configuration or return 
to the main menu and exit to perform customization of the 
environment. 


Do you want to (c)ontinue or (r)eturn to the main menu? (c/r) 


[c]: 


e If you enter r, the dmu utility returns tothe DMU Main Menu tolet 
you exit the dmu utility and modify the /etc/.proto.. files. 


¢ Ifyou enter c to continue, the dmu utility displays progress messages 
as it configures each software subset, similar tothe following output: 


Configuring "Base System " (OSFBASE505) 
Configuring "Base System-Hardware Support" (OSFHWBASE505) 


{subset list} 


Configuring "Remote Installation Service" (OSFRIS505) 
Configuring "Dataless Management Services" (OSFDMS505) 


After you have created at least one DMS environment, installed software, 
customized the .proto.. files, and configured the DMS environment, you 
can add clients to the environment as discussed in Chapter 12. 


11.5 Installing WLS Support in DMS 


This section tells you how to install WLS support in DMS, and includes 
the following topics: 


¢« Setting up aDMS server for WLS (Section 11.5.1) 
¢« Setting up aDMS client for WLS (Section 11.5.2) 
¢ Building an Asian kernel for DMS clients (Section 11.5.3) 


11.5.1 Setting Up a DMS Server for WLS 


Follow these steps to create a new dmsN .alpha environment and install 
WLS software from a base operating system CD-ROM: 


1. Logintothe DMS server as root or use the su command to gain 
superuser privileges. 


2. Install the operating system into a DMS area before installing the 
Worldwide Language Support (WLS) software. 


3. Load the CD-ROM containing the WLS subsets into your CD-ROM 
drive and enter a mount command similar to the following: 


mount -dr -t cdfs -o rrip /dev/disk/cdrom0c /mnt 
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4. Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu. 


5. Select INSTALL software environments. You see the DMU 
Software Installation Menu. 


6. SelectAdd software to an existing area. 


If you have more than one DMS environment, you see a list of available 
DMS environments and you are prompted to select the environment 
for adding software. 


7. Select the DMS area where the operating system is installed. You are 
prompted for the location of the software. 


8. Enter the full pathname of the device special file or mount points for 
the distribution media. Enter /mnt /ALPHA/WORLDWIDE toinstall WLS 
subsets. You see a menu listing the countries for which you can install 
worldwide language support. 


9. Select the software to support the countries that you want to install. 
You see a list of available subsets. 


Refer to Section 11.3 for instructions on installing subsets. 
After installing the subsets, you see the DMU Main Menu. 


10. Select CONFIGURE software environments to configure newly 
installed subsets into the DMS environment. 


Refer to Section 11.4.2 for instructions on configuring DMS 
environments. 


11.5.2 Setting Up a DMS Client for WLS 


11.5.3 


Once you have set up the DMS areas and registered the clients, they can 
access the configured areas. See Section 10.8 on how to register the client 
with a network naming service. You must register the dient with the full 
or partial (default) kernel option for the client to use the Asian kernel 
functionality. 


Building an Asian Kernel for DMS Clients 


When the DMS client boots for the first time from a newly configured DMS 
area, an Asian kernel is built. Reboot the system if you want to use the 
Asian terminal driver functions. You also can reconfigure the Asian kernel 
on the client machine by using the wwconfig command as follows: 


# /usr/sbin/wwconfig -a 


Refer to the Installation Guide — Advanced Topics and the wwconfig(8) 
reference page for more information about using the wwconfig command. 
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Managing DMS Clients and Environments 


This chapter describes how to use the dmu utility to manage Dataless 
Management Services (DMS) environments and clients. The information in 
this chapter includes the following topics: 


¢ Locating and interpreting the DMS client database file (Section 12.1) 

¢« Addinga client toa DMS environment (Section 12.2) 

* Bootinga DMS client (Section 12.3) 

¢ Deletinga DMS environment (Section 12.4) 

¢« Modifying a DMS client (Section 12.5) 

« Removing a DMS client (Section 12.6) 

e Listing registered DMS clients (Section 12.7) 

¢ Showing software environments in the server’s DMS area (Section 12.8) 
¢« Maintaining the server’s DMS areas (Section 12.9) 


12.1 DMS Client Database File 


The DMS client database is located in the /var/adm/dms/clients/dmsdb 
file. Entries in this file are similar to the following: 


client1 :xx-xx-xXx-xx-xx-xx:/var/adm/dms/dms0.alpha:/clients/clientl1: 
rz0b:RZ26:None:1n0:255.255.255.0 


In this example: 
* clienti1 is the client’s host name 
° xxX-XxXx-XX-xXxX-xx-xx is the client’s hardware network address 


« /var/adm/dms/dms0.alpha is the DMS environment being served 
to the client 


¢ /clients/client1 is the location of the client’s root area 
* rz0b is the client’s swap device and partition 

* RzZ26 is the swap disk 

* None specifies the client has no kernel build area 

* ino is the network interface type 

* 255.255.255.0 is the network subnet mask 


Managing DMS Clients and Environments 12-1 


When you use add, modify, or deletea DMS client fromthe DMU Main Menu, 
the client’s entry in the dmsdb file is added, modified, or deleted, respectively. 


12.2 Adding a DMS Client 


The information you need to add a DMS client is shown in the Client Setup 
Worksheet in Appendix B. Fill out a worksheet for each client you want to 
add before you use the dmu utility to add clients toa DMS environment. 


Before you can add a client, you already must have followed the procedures in 
Chapter 11 toinstall software in at least one DMS environment. Optionally, 
you may want tocustomize the .proto. . files as described in Section 11.4.1. 


TheDMS client must be connected to a local area network (LAN) and must be 
registered with the DMS server through one of the network naming services 
(see Section 10.8) or must have an entry in theserver’s /etc/hosts file. 


When you add a client toa DMS environment, the root directory from the 
server’s DMS environment gets copied to the client area. 


F ollow these steps to add a client toa DMS environment: 


1. Logintothe DMS server as root or use the su command to gain 
superuser privileges. 


2. Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu: 


*** DMU Main Menu *** 


) ADD a client 

) CONFIGURE software environments 
) DELETE software environments 

) INSTALL software environments 

) LIST registered clients 
) 

) 

) 

) 


o@ 


rFPRadaQ 


MODIFY a client 

REMOVE a client 

SHOW software environments 
EXIT 


3 


nH 


% 


Enter your choice: 


3. Enter atoselect ADD a client. You seea prompt similar tothe 
following: 


You have chosen to add a client for dataless service. 
The following conditions must be met to add a client: 
1. You must know the client processor’s hostname. 


2. The client’s hostname must be in your system’s host 
database(s) . 
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3. You must know the client’s interface type, subnet 
mask. 

4. You must know the type of kernel build area. 

5. You must know the swap device and partition on the 
client. 

6. You must know the client’s hardware Ethernet or FDDI 
address. 

7. If the client and the server reside on different subnets, 
you will need the address of the gateway(s) that the 
client can sue to communicate with the server. 


Do you want to continue? (y/n) [y]: 
Enter y to continue. You see the following prompt: 
Enter the client processor's hostname or press RETURN to quit: 


Enter the host name for the DMS client. 


If you enter a host name that is not in the server’s host database, you 
see a message similar to the following: 


arp failed on hostname "client1" 


In the above message, arp is the Address Resolution Protocol. If you 
receive this message, check the /etc/hosts file to determine the 
correct host name. If the client was never registered with a network 
naming service (such as BIND or NIS) or was never entered in the 
/etc/hosts file, press Ctrl/C to exit the dmu utility and manually add 
the client to the /etc/hosts file before you restart the procedure. 


Note 


For the remaining examples, assume that the Return key is 
pressed to accept the default response. 


You see a prompt similar to the following: 
Enter the path to contain the root file system. [/clients/client1]: 


Enter a path, or press Return for the default, /clients/hostname. If 
you specify a path other than the default , the directories in that path 
must already exist. The path must begin with /clients, and can beno 
longer than 25 characters. 


For example, if you want to differentiate between client 

systems in different departments at your site, you could specify 
/clients/deptname/ hostname as the root location. The deptname 
directory must exist already under the /clients directory. 


You see a prompt similar to the following: 


Enter the swap device and partition on client1l. [dskob] : 
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7. Enter the swap device and partition on the DMS client. You seea 
prompt similar to the following: 


Enter the swap device drive type for dsk0Ob. [RZ26]: 


8. Enter the swap device drive type for your previous entry. You see a 
prompt similar to the following: 


Enter the network interface for clientl 
(nn.nn.nnn.nnn) [l1n0]: 


9. Enter the DMS dient’s network hardware address. You see a prompt 
similar to the following: 


Enter the subnet mask for 1nO. [255.255.255.0]: 
10. Enter the DMS client’s network subnet mask. 
You may see the following prompts: 


¢ Ifthe DMS cient is on a different subnet than the DMS server, you 
see a prompt similar to the following: 


Enter the default route for network nn.nn.nnn 
[nn.nn.nnn.nnn]: 


Note 


The default network interface is 1no for the DEC 3000 
series and other systems that use the Lance Ethernet 
module. Some systems such as the EB64+ use the Tulip 
Ethernet module, which may be identified as tuo. Be 
sure to enter the correct network device identifier for the 
Ethernet or FDDI interface on the client system. 


e If there is an entry for the client’s subnet in the 
/var/adm/dms/gateways file on the server, the following message 
is displayed: 

The following are the known gateway[s] between the client subnet and 
server subnet. If these value[s] are not correct, please enter the 
proper address[s]. If these value[s] are correct, press Return. (For 
example, nn.nn.nnn.???) [nn.nn.nnn.nnn): 

e If there is no entry for the client’s subnet in the 
/var/adm/dms/gateways file on the server, you see a prompt 
similar to the following: 


Enter the IP address of the gateway[s] between the client subnet and 
server subnet. (For example, nn.nn.nnn.???) : 


Refer to the Network Administration guide for information about 
obtaining the client’s network information. 
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11. 


12. 


13. 


14. 


You see a prompt similar to the following: 


Enter the type of kernel build area for clientl. 
You may select one of [F]ull, [P]artial, [N]one or 
{[H]elp for more information. [P]: 


Enter the letter corresponding with the type of kernel build that you 
want. You see a prompt similar to the following: 


You have specified the following configuration for clientl: 


ROOT: /clients/client1 

SWAP DEVICE: /dev/disk/dsk0b 

SWAP_TYPE: RZ26 

BUILD TYPE: Partial 

INTERFACE: 1n0 (nn.nn.nnn.nnn) 

SUBNET MASK: 255.255.255.0 
ROUTE: network: nn.nn.nnn gateway: nn.nn.nnn.nnn 
Is this correct (y/n) [y]: 


Enter y toconfirm your selections or n toreturn tothe DMU Main Menu. 
If you enter y, you see a prompt similar to the following: 


= 


[The existing environment is /var/adm/dms/dms0.alpha. 


A 


The following environment will be installed from 
/var/adm/dms/dms0.alpha: 


Description 
He ‘Tru64 UNIX VAAA Operating System (Rev nnn)’ 


Is that correct? (y/n) [yl]: 


If there is more than one DMS environment, you are prompted to select 
one and confirm your selection. 


Enter y toconfirm your selection or n toreturn tothe DMU Main Menu. 
You see a prompt similar to the following: 


Enter the client processor’s hardware network 
address. For example, 08-00-2b-02-67-e1: 


Enter the DMS dcient’s hardware network address. 


Note 


The dms utility does not check the validity of the address you 
enter, but it does check to make sure the address you enter is 
in the correct format. 


Managing DMS Clients and Environments 12-5 


You see a prompt similar to the following: 


Checking file system space required for client 
root and var file systems. 


¢ |f there is not enough free space available to create the file systems, 
you see a prompt similar to the following: 


There is not enough free space in /clients 
to create the root and var file systems 
for client1l. client1l has not been added. 


e |f there is enough free space to create file systems, you see the 
following prompt: 


Creating the root and var file systems for clientl 


Client clientl has been added. 
You see the DMU Main Menu. 


Notify the client’s system administrator when client registration is complete 
and inform them that they now can boot the client across the network. 

See Section 12.3 for basic information about booting a client. Refer tothe 
Installation Guide — Advanced Topics for additional information. 


12.3 Booting a DMS Client 


After a DMS client is added to the appropriate environment, the client’s 
system administrator can boot the client over the network. When 

the client starts to boot, the kernel that boots over the network is: 
/clients/hostname /.vmunix 


The following steps occur when the client boots: 


1. The/clients/hostname directory is mounted by NFS as root (/). 


2. The/var/adm/dms/dmsN.alpha/root/usr directory is mounted by 
NFS as /usr. 


The network information you entered about the dient when you added it to 
the DMS environment is sufficient to boot the DMS client across the LAN. 


DMS clients must be able to boot over Ethernet or FDDI LAN. The basic 
procedure for booting a processor over the network from a server is to shut 
down the client system to console mode and then issue a boot command 
from the client. 


Refer to the Installation Guide — Advanced Topics for information about 
booting systems over the network. 
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When the client system boots, the client system administrator is prompted 
to enter a superuser password: 


**k* SUPE 


RUS 


ER PASSWORD SPI 


ECIFICATION ** 


Changing password for root. 


Enter root password: 
Retype root password: 


System information is displayed while the client system boots. When the 
Common Desktop Environment (CDE) login window or the login prompt 
appears, enter root as the login name. At the prompt for a password, enter 
the superuser password that was specified previously. 


12.4 Deleting a Software Environment 


When you delete a software environment, the environment itself and all 
clients registered to that environment are deleted. Once you confirm your 
choice, there is no opportunity to undo the deletion. 


Caution 


Make sure that the clients registered to the environment have 

been notified and shut down before you delete the environment. 
Failure to do so will cause a running client to lose its operating 
system. 


To delete a software environment, follow these steps: 


1. Logintothe DMS server as root or use the su command to gain 
superuser privileges. 


2. Enter /usr/sbin/dmu to start the DMS utility. You see the DMU Main 
Menu: 


*** DMU Main Menu *** 


o@ 


3Brraa 


nh 


) 
) 
) 
) 
) 
) 
) 
) 


% 


) ADD a client 


CONFIGURE software environments 


EXIT 


Enter your choice: 


DELETE software environments 
INSTALL software environments 
LIST registered clients 
MODIFY a client 

REMOVE a client 

SHOW software environments 
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3. Enter dtoseect DELETE software environments. You seea prompt 
similar to the following example, which lists three DMS environments: 


Select the remote dataless environment: 


1) /var/adm/dms/dms0.alpha 
‘Tru64 UNIX VAAA Operating System (Rev nnn)’ 


2) /var/adm/dms/dms1.alpha 
‘Tru6é4 UNIX VBBB Operating System (Rev nnn)’ 


3) /var/adm/dms/dms2.alpha 
‘Tru64 UNIX VCCC Operating System (Rev nnn)’ 


Enter your choice: 


4. Enter the number that corresponds to the DMS environment you want 
to delete, for example: 1. You see a prompt similar to the following: 


After you select the dataless environment to delete, a confirmation 
displays your choice: 
The following environment will be deleted from 


/var/adm/dms/dms0.alpha: 


Description 
‘Tru64 UNIX VAAA Operating System (Rev nnn)’ 
Is that correct? (y/n) [yl]: 
5. Confirm your selection. 
e If you enter n, the dmu utility returns tothe DMU Main Menu. 
¢ If you enter y, you see a prompt similar to the following: 
After this deletion, the area /var/adm/dms/dms0.alpha will 
be empty. The following clients are registered for 
/var/adm/dms/dms0.alpha: 


client1 client2 client3 


This procedure will completely remove /var/adm/dms/dms0.alpha. 
Do you want to continue? (y/n) [nl]: 


- If you enter n, the dmu utility returns tothe DMU Main Menu 
and does not delete the environment or its registered clients. 


- If you enter y, you see a prompt similar to the following: 


Do you want to remove the client’s root file system 
[/clients/client1]? (y/n) [nl]: 


This is your opportunity to save customized data in the root 
directory. If you enter n, all customized data in the root directory 
is lost. 
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The dmu utility also prompts you to remove the root and /var 
file systems for each client registered to the environment. 


Once you confirm your selections, the dmu utility proceeds to delete 
the DMS environment and all its registered clients. 


After the DMS environment is deleted, the dmu utility returns to the DMU 
Main Menu. 


12.5 Modifying Client Information 


The dmu utility lets you modify the network hardware address of a client. 
Refer to Section 1.3 for instructions about how to obtain the hardware 
address of a client. 


Perform the following steps to modify a DMS client’s information: 


1. 


Login tothe DMS server as root or use the su command to gain 
superuser privileges. 


Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu: 


*** DMU Main Menu *** 


REMOVE a client 
SHOW software environments 
EXIT 


nh 


a) ADD a client 
c) CONFIGURE software environments 
d) DELETE software environments 

1) INSTALL software environments 
1) LIST registered clients 
m) MODIFY a client 

) 

) 

) 


x 


Enter your choice: 


Enter mtoselect MODIFY a client. You seea prompt similar tothe 
following: 


The following clients are available to modify: 


client4 client5 client6 


Enter the client processor's hostname or press RETURN to quit: 


Enter the name of the client you want to modify, for example: client4. 
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You see a prompt similar to the following, with the DMS client’s current 
hardware network address as the default response: 


Enter the client processor’s hardware network address. For 
example, 08-00-2b-02-67-el1 [xx-xx-xXxX-XX-XxX-xx]: 
Caution 


The dms utility checks the format of the address you enter 
but does not check its validity. 


5. Enter the DMS client’s hardware network address or press Return to 
accept the default. You see a message similar to the following: 


Client client4 has been modified. 


*** DMU Main Menu *** 


a) ADD a client 

c) CONFIGURE software environments 
d) DELETE software environments 

1) INSTALL software environments 
1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software environments 

x) EXIT 


Enter your choice: 


If you want to change the client’s |P address or the environment to which 
the client is registered, follow these steps: 


1. Login tothe DMS client as root or use the su command to gain 
superuser privileges. 


2. UsetheSysMan Menu or the shutdown -h command to shut down 
the DMS client. 


3. LogintotheDMS server as root or use the su command to gain 
superuser privileges. 


4. Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu: 


*** DMU Main Menu *** 
a) ADD a client 


c) CONFIGURE software environments 
d) DELETE software environments 
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1) INSTALL software environments 
1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software environments 

x) EXIT 


Enter your choice: 


Enter r toselect REMOVE a client, and follow the instructions in 
Section 12.6. You see the DMU Main Menu again. 


Enter a toselect ADD a client, and follow the instructions in 
Section 12.2. 


Restart the DMS client. 


12.6 Removing a Client 


Follow these steps to remove a client from a DMS environment: 


1. 


Login tothe DMS client as root or use the su command to gain 
superuser privileges. 


Usethe shutdown -h command toshut down the DMS client. 


Log into the DMS server as root or use the su command to gain 
superuser privileges. 


Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu 


*** DMU Main Menu *** 


a) ADD a client 

c) CONFIGURE software environments 
d) DELETE software environments 

1) INSTALL software environments 
1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software environments 

x) EXIT 


Enter your choice: 
Enter r toselect REMOVE a client. You see the following prompt: 


You have chosen to remove a client from the remote 
dataless service. 


Enter the client processor’s hostname or press RETURN to quit: 


Managing DMS Clients and Environments 12-11 


6. Enter the DMS client’s host name, for example: client5. You seea 
prompt similar to the following: 


Remove client5? (y/n) [nl]: 


7. Enter y to delete the client. The dmu utility removes the client’s 
registration to the DMS environment, along with the following 
additional items: 


¢ Theclient’s root directory (including any customized files that may 
have been added to that directory) 


« TheDMS client’s entriesin /etc/exports (described in Chapter 13) 

¢ TheDMS client's entries in /etc/bootptab 

« TheDMS client’s entry in the DMS client database file (described in 
Section 12.1). 


If you remove a client but save the root (/) file system, you cannot reuse that 
root file system if you subsequently add a client with the same client name. 


12.7 Listing DMS Clients 
Follow these steps to view registered DMS clients: 


1. Logintothe DMS server as root or use the su command to gain 
superuser privileges. 


2. Enter /usr/sbin/dmu tostart the dmu utility. You seethe DMU Main 
Menu: 


*** DMU Main Menu *** 


) ADD a client 

) CONFIGURE software environments 
) DELETE software environments 

) INSTALL software environments 

) LIST registered clients 
) 

) 

) 

) 


MODIFY a client 

REMOVE a client 

SHOW software environments 
EXIT 


Enter your choice: 


3. Enter 1toselect LIST registered clients. 
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You see output similar to the following: 


A 


[The following clients are registered for /var/adm/dms/dms0.alpha: 
client1l client2 client3 
The following clients are registered for /var/adm/dms/dms1.alpha: 
client4 client5 clienté6 


A 


[The following clients are registered for /var/adm/dms/dms2.alpha: 
client7 clients client9 


12.8 Showing Software Environments 


The dmu utility lets you display a list of the current DMS environments: 


1. 


Log into the DMS server as root or use the su command to gain 
superuser privileges. 


Enter /usr/sbin/dmu to start the dmu utility. You seethe DMU Main 
Menu: 


*** DMU Main Menu *** 


a) ADD a client 

c) CONFIGURE software environments 
d) DELETE software environments 

1) INSTALL software environments 
1) LIST registered clients 

m) MODIFY a client 

r) REMOVE a client 

s) SHOW software environments 

x) EXIT 


Enter your choice: 


Enter s toselect SHOW software environments. You see output 
similar to the following: 


1) /var/adm/dms/dms0.alpha 
‘Tru6é4 UNIX VAAA Operating System (Rev nnn)’ 


2) /var/adm/dms/dmsl1.alpha 
‘Tru6é4 UNIX VBBB Operating System (Rev nnn)’’ 


3) /var/adm/dms/dms2.alpha 
‘Tru64 UNIX VCCC Operating System (Rev nnn)’’ 


*** DMU Main Menu *** 


a) ADD a client 
c) CONFIGURE software environments 
d) DELETE software environments 
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i) INSTALL software environments 
1) LIST registered clients 

m 

r) REMOVE a client 


n 


SHOW software environments 


) 

) 

) MODIFY a client 
) 

) 

) EXIT 


x 


Enter your choice: 


12.9 Maintaining the DMS Environment 
This section contains information about maintaining the DMU server area, 
and includes the following topics: 
¢ Controlling root file system growth (Section 12.9.1) 
e Listing installed software subsets (Section 12.9.2) 
e« Removing software subsets (Section 12.9.3) 


12.9.1 Controlling Root File System Growth 


The d£ command displays statistics about the amount of free space on a 
specified file system or on a file system that contains a specified file. 


The du command displays a summary of disk usage for file systems. Use 
this command to monitor the file growth in each client’s root directory. If 
clients use too much space, performance is adversely affected. Users must 
then be told to delete all unnecessary files from their file systems. Monitor 
disk usage periodically depending upon the systems’ use. 


Refer to the d£(1) and du(1) reference pages for more information about 
monitoring file system growth. 


12.9.2 Listing Installed Software Subsets 


Use the set1d utility to determine which software subsets are installed 
intoa particular dmsN .alpha area. For example, the following command 
produces a list of the subsets installed into the client root area of 
/var/adm/dms/dms0.alpha: 


# setld -D /var/adm/dms/dms0.alpha/root -i 


Refer to the set 1d(8) reference page for more information. 
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12.9.3 Removing Subsets 


Use the set1d utility to remove software subsets from a dmsN .alpha 
area. For example, if you want to remove the Document Preparation Tools 
Extensions subset, OSFDCMTEXT505, usea command similar to the following: 


# setld -D /var/adm/dms/dms0.alpha/root -d OSFDCMTEXT505 


The Installation Guide contains a list of all software subsets. 


Caution 


If the set1d utility placed files in the root file system during 
the installation, the product may not be fully removed from the 
client’s root file system. Be careful about removing any subset 
that may be used by client systems. For example: 


e If you remove a subset that contains kernel build files, the 
clients may not be able to build new kernels. 


e If you remove a subset that contains NFS components, the 
clients may not be able to reboot. 


You should understand client dependencies before you remove a 
software component. You may need to delete and reregister all 
clients before you can reload a subset. 


Managing DMS Clients and Environments 12-15 


13 


Troubleshooting DMS 


This chapter contains information to assist you in troubleshooting problems 
with DMS. If a DMS client has trouble booting, you can check several aspects 
of server operation to ensure that the server's end of the network connection 
is functioning properly. These are grouped into the following categories: 


« Removing DMS lock files (Section 13.1) 

¢« Checking NFS server status (Section 13.2) 

¢« Checking network daemon status (Section 13.3) 

¢« Checking directory exports (Section 13.4) 

e Checking server-client compatibility (Section 13.5) 

¢ Correcting swap device problems (Section 13.6) 

¢ Reconfiguring for a hardware update release (Section 13.7) 


13.1 Removing DMS Lock Files 


To prevent multiple users from performing simultaneous operations on DMS 
areas, the dmu utility creates two lock files in the /tmp directory, dmslock 
and dms.tty.lock when you areinstalling or deleting softwareina DMS 
area. If another user (or the same user on a different terminal) runs the dmu 
utility and attempts to install or delete software from the DMU Main Menu, 
they see a message similar to the following: 


The dmu utility is currently locked while j_ smith on /dev/ttyp3 
is installing software. Try again later. 


If the dmu utility is stopped prematurely, these lock files may not be removed 
and you see this message even though no other user is using DMS. You must 
delete the lock files from the /tmp directory. 


Caution 


Before deleting the lock files, ensure that no other user is using 
the dmu utility. 
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13.2 Checking NFS Server Status 


Some DMS client boot problems occur if the DMS server is not a Network 
File System (NFS) server. To check whether or not a DMS server is an NFS 
server, enter the following command on the DMS server: 


# remgr get NFSSERVING 


If the response is a1, the system is an NFS server. If the response is a 0, 
the system is not an NFS server. Run nfsconfig to configure the server 
to bean NFS server. Refer to the nfsconfig(8X) reference page for more 
information about this utility. 


13.3 Checking Network Daemon Status 


Some DMS client boot problems occur if the network daemons are not 
running on the DMS server. This condition is indicated on the DMS client 
with a message similar to the following: 


panic: vfs_mountroot: cannot mount root 


If you see this message on the DMS client, check to make sure that the 
following daemons are running on the DMS server: 


°* portmap 
* mountd 
e nfsd 


e nfsiod 


Enter the following command on the DMS server to see if the network 
daemons are running: 


# pS ax rep -E "portmap|mountd|nfsd|nfsiod" 
Pp g 


You see process status for any of those daemons that are running, as well 
as a line showing your grep command. If the daemons are not all running, 
you must start the inoperative ones. 


13.4 Checking Directory Exports 


Some DMS client boot problems occur if the client’s directories are not 
exported correctly. If the DMS client boots to single-user mode but 

will not boot to multiuser mode, check the entries in the DMS server’s 
/etc/exports file and ensure that the /usr file system and dmsN root area 
entries in /etc/exports are correct, similar to the following example for a 
DMS dient named client1 registered tothe /var/adm/dms/dms0.alpha 
DMS area: 


/clients/clientl -r=0 clientl 
/var/adm/dms/dms0.alpha/root/usr -r=0 -ro 
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Refer to the exports(4) reference page for information about the 
/etc/exports file. 


13.5 Checking Version Compatibility 


If you cannot execute commands on the DMS client and the DMS server and 
client are running different versions of the operating system, check to see 

if you copied the client’s dmu version to the server. Refer to Section 11.1 

for more information. 


13.6 Correcting Swap Device Problems 


If there is a problem with the disk or disk partition that was designated as 
the swap device when the client was registered, you may see a message 
similar to the following: 


WARNING: 
: Swap is being set to lazy (over commitment) mode. The system will 
: come up to single-user mode. Set fstype for swap partition to 
: "swap" using "disklabel -s swap" command and reboot. 


/dev/device/name swap partition has unused fstype, failed to add swap. 


Use one of the following procedures to correct this problem: 


If you are using an older version of the operating system that uses 
traditional device naming conventions (/dev/rrzNc), follow these steps: 


1. 


5. 


Logintothe DMS client as root or use the su command to gain 
superuser privileges. 


Change directory to /dev. 
# cd /dev 


Run the MAKEDEV utility on the disk or disk partition designated 
as the swap device. 


# ./MAKEDEV swapdev 


Set the file system type for the swap device by running the 
disklabel utility. Remember to specify swapdev as a raw device. 


# disklabel -sF /dev rswapdev swap 
Shut down and reboot the DMS client. 


If you are using a later version of the operating system that uses newer 
device naming conventions (/dev/disk/cdromNc), follow these steps: 


1. 


Logintothe DMS client as root or use the su command to gain 
superuser privileges. 


Change directory to /dev/rdisk. 


# cd /dev/rdisk 
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3. Set the file system type for the swap device by running the 
disklabel utility. 


# disklabel -sF /dev/rdisk swapdev swap 
4. Shut down and reboot the DMS client. 


13.7 Reconfiguring for a Hardware Update Release 


If you are installing a hardware update release and you configure the DMS 
environment before you add the operating system hardware update, you 
must connect to the root directory in the DMS environment and issue the 
following two commands to undo the configuration: 


# rm -rf usr/sys/conf/DATALESS 
# rm -rf usr/sys/DATALESS 


Refer to Appendix D for information about hardware update releases in 
DMS. 


13-4 Troubleshooting DMS 


A 


RIS Worksheet 


This appendix contains a worksheet for recording setup information for the 
RIS client. Make as many copies of this worksheet as you need. 
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RIS Client Configuration Worksheet 


Network System name: 


Network hardware address 


IP network address: 


Internet domain: 


RIS Info Client operating system: 


Processor architecture: 
Server system name: 
RIS environment name: 


Products: 


eNte-lfll Duplicate another client? No 


Name of client to copy: 


ZK-0618U-Al 
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DMS Worksheets 


This appendix contains three DMS worksheets. Two of the worksheets 

are used to calculate the amount of disk space required for the DMS 
environments and /clients area. The third worksheet is used to record 
individual DMS client information. Makeas many copies of these worksheets 
as you need. The worksheets are printed on only one side of the page so 
you can photocopy them easily. To keep all your calculations together, use 
the back side of each worksheet for additional notes or for calculating the 
numbers you insert into fields on the worksheet. 


The following worksheets are included: 


¢ Disk space allocation for the /var/adm/dms/dmsN .alpha environments 
¢ Disk space allocation for the /clients area 
¢ Individual DMS client information 
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Disk Space Required for Dataless Environments 


Use this worksheet to calculate the amount of space required for a single 
/var/adm/dms file system. If you want multiple /var/adm/dms 
environments, you must prepare a separate sheet for each environment. 

Each environment has a number: the first is /var/adm/dms/dms0.alpha, 
the second is /var/adm/dms/dms1.alpha,and soon. Fill in the number of 
this /var/adm/dms/dmsn.alpha environment on the top line. 


Disk Space for the /var/adm/dms/dms . alpha File System 


Using the appropriate subset size information, follow these steps to find how 
much space you need for a /var/adm/dms/dms n.alpha environment: 


Decide which subsets and layered products you want to install, 
add up their total sizes in megabytes, and enter the sums here. 
Subset names and descriptions are located in the /nstallation Guide; 
subset sizes are located in the Release Notes. 
MANDATORY subset space: MB 
OPTIONAL subset space: MB 


Layered product space: _____________ MB 


Add up the sizes from step 1 to arrive at the amount of space 
your dataless environment will require. 


Subtotal: 


Allocate an additional 10% of the space from step 2 for file 
system administration and other information. Enter that 
number here: 


10% overhead space: 


Add together the amounts of space from steps 2 and 3. 
The total is the amount of space you should allocate for this 
environment. 


Total space for/var/adm/dms/dms __.alpha: 


ZK-1017U-Al 
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Disk Space for the /clients File System 


Using the appropriate memory size information for your clients, follow these 
steps to find how much space you need for the /clients area. 


To allow at least 30 megabytes(MB) for an individual client’s root 
area, multiply the number of clients in the /clients area by 30. 


Number of clients ( )x 30 =__ CCB 


Allocate an additional 15 MB per client for files added by users. 
Multiply the number of clients by 15 and enter that value here. 


Number of clients ( )x15=___COCOCMMB 


Allocate an additional 15 MB for clients that have partial kernel 
build areas. Multiply the number of clients with partial kernel 
build areas by 15 and enter that value here. 


Number of clients ( )x15= 


Allocate an additional 100 MB for clients that have full kernel build 
areas. Multiply the number of clients with full kernel build areas 
by 100 and enter that value here. 


Number of clients ( ) x 100 = 


Add the above figures. The total is the amount of space 
you should allocate for the /clients area. 


Total space for /clients file system: 


ZK-1018U-Al 
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DMS Client Setup Worksheet 


This worksheet is used for recording the information you need to know when 


adding a client to a DMS environment using the ADD a client menu 


option. If you are adding multiple clients, you must prepare a separate sheet 
for each client. Fill in the client's system name (host name) on the next line. 


Registration Information for DMS Client 


Network The client’s Ethernet or FDDI hardware address in the form 


of six two-character groups separated by minus signs. 


For example, 08-00-2f-03-f5-08 5 ; ; | : 


The client’s network interface type. 
For example, InO or tu0, etc. 


The client’s subnet mask. 


For example, 255.255.255.0 
The client’s route address. 


(gateway FROM the client TO the server) 


For example, 16.69.144.199 
The route address is only required if the server and client are on different networks. 


DMS Information 


The name of the dataless environment to which this client 
will be added. For example, 
/var/adm/dms/dms N.alpha 


The name of the /clients area. 


For example, /clients/hostname 


The client’s swap device and partition. 
For example, /dev/disk/dsk0b 


The client’s swap device type. 


For example, RZ26 


The kernel build type (Full, Partial, 
or None) 


ZK-1520U-Al 
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Using the utilupdate Utility 


Use the utilupdate utility provided on your distribution media to update 
the ris and dmu utilities on a server that is running an older version of 
the operating system. This enables you to serve the latest version of the 
operating system to client systems. 


Syntax for the utilupdate utility is as follows: 

utilupdate [-r] [-d] -m directory 

There are three parameters for the utilupdate utility: 

oa This optional flag indicates that the ris utility and associated 


programs should be updated. 


-d This optional flag indicates that the dmu utility and associated 
programs should be updated. 


aut This required flag is used to specify the directory where the 
operating system distribution is mounted. 


Note 


If you do not specify the -r or -d parameter, the utilupdate 
utility only updates the components of the set1d utility needed to 
support the ris and dmu utilities on the server. This updates the 
version of the set1d utility in the /var/adm/ris/bin directory, 
but does not change the server’s version of the set1d utility. 
Refer to the set 1d(8) reference page for more information. 
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D 


Hardware Update Releases in DMS 


A hardware release is a version of the operating system that includes new 
or updated kernel modules to support hardware devices. In the current 
version of the operating system, the function of hardware releases has been 
superseded by the New Hardware Delivery (NHD) process and, to a lesser 
degree, hardware product kits. 


This appendix includes the following topics: 


¢« An overview of hardware releases, describing how to prepare for the 
installation (Section D.1) 


e Instructions for installing a hardware release into a DMS area 
(Section D.2) 


D.1 Overview 


If you are serving an older version of the operating system from DMS where 
hardware releases are applicable, you may need to install a hardware 
release intoa DMS environment. The procedures in this appendix assume 
that the DMS area is serving a version of the operating system no earlier 
than Version 3.2C and no later than Version 4.0C. 


Depending upon how you are installing the hardware release, you should 
check the following information before you start: 


e You can install the new hardware release from a locally mounted 
CD-ROM. Refer to Section 1.3 if you do not know your CD-ROM drive's 
device name. 


e You can install the new hardware release from a CD-ROM mounted 
using NFS froma remote server or froma RIS area exported using NFS 
from a RIS server where the new release has been installed. Refer to 
Section 4.5 for information about using a RIS area mounted on NFS. 


If you install the new hardware release from a RIS area, you must know 
the following information: 


- Which product areas in your /usr/var/adm/ris/ risN .alpha 
contain each of the product kits you need to install. Refer to 
Section 6.7 to list products in a RIS area. 


Hardware Update Releases in DMS D-1 


- Which directory in the RIS area conains the operating 
system software. Examine the /usr/var/adm/ris/risN 
.alpha/ProdNames file to determine this directory. 


¢ If you install from a base operating system CD-ROM mounted on the 
mount point /mnt, the /mnt /ALPHA/UPDATE directory contains the 
operating system hardware update release. 
D.2 Installing a Hardware Release into a DMS Area 


Follow these steps to install the operating system hardware update release 
into an existing DMS area: 


1. Follow the instructions in Section 11.2 toinstall the previous version of 
the operating system into a new DMS environment. 


Caution 


Do not configure the DMS environment at this time. 


2. Follow theinstructions in Section 11.3 to install the hardware update 
release into the same DMS environment that you created in the 
previous step. 


3. Follow the instructions in Section 11.4 to configure the DMS 
environment. 


You can now serve DMS clients from the updated operating system hardware 
release. 


Note 


Section 12.8 explains how to use the dmu utility to show DMS 
software environments. This procedure displays only the 
operating system product name in each DMS environment. 
To determine if a hardware release is installed ina DMS 
environment, use the set1d command. 


For example, the following command produces a list of the subsets 
installed into the client root area of /var/adm/dms/dms0.alpha: 


# setld -D /var/adm/dms/dms0.alpha/root -i 


Refer to the set 1d(8) reference page for information about this 
command. 
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Glossary 


This glossary defines terms and concepts related to software sharing. 


BIND 


The Berkeley Internet Name Domain. A distributed database lookup service 
that allows you to distribute the hosts database network-wide. 


boot command 

The boot command performs the initial installation and bootstrap of 

the operating system. You invoke the boot utility from the >>> console 
prompt. Refer to your hardware documentation for information about valid 
parameters for the boot utility on your system. 


CDF 
Configuration description file. There are two kinds of CDFs: 


¢« Aninstallation CDF (install .cd£) contains the results of the questions 
answered during the installation and is stored in the /var/adm/smlogs 
directory. You can copy and modify this file to use for Installation 
Cloning. 


¢ A configuration CDF (config.cd£) contains network, internet, printer, 
and mail configuration information that save from a fully installed and 
configured system with the sysman -clone -save command. This file 
can be applied to a target system during a Full Installation, or it can be 
applied manually to a running system. 


CDSL 


A context-dependent symbolic link (CDSL) is a special form of symbolic 
link that dynamically resolves to a member-specific file, depending upon 
the cluster member accessing the file. CDSLs make it possible to maintain 
system-specific configuration and data files on file systems shared by the 
cluster. 


See also cluster, cluster member, member-specific file shared file 


client 


A computer system that uses resources provided by another computer, 
called a server. 
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See also server 


client area 
In DMS, an area containing a single client’s custom-tailored root files 
including the operating system kernel. 


cluster 

A loosely-coupled collection of servers that share storage and other 
resources, providing high availability of applications and data. A cluster 
consists of communications media, member systems, peripheral devices, and 
applications. One system can form a single-member cluster. 


See also cluster member 


cluster alias 


An IP address used to address all or a subset of the cluster members. A 
cluster alias makes some or all of the systems in a cluster look like a single 
system when viewed from outside the cluster. 


See also cluster, cluster member 


cluster member 

A system configured with TruCluster software that is capable of joining a 
cluster. A cluster member must be connected physically to a private physical 
bus for intracluster communications and at least one shared SCSI bus. 


See also cluster 


configuration description file 
See CDF 


context-dependent symbolic link 
See CDSL 


Dataless Management Services 
See DMS 


DHCP 

Dynamic Host Configuration Protocol. Enables the automatic assignment 
of an IP address to clients on networks from a pool of addresses. The IP 
address assignment and configuration occurs automatically whenever 
appropriate client systems (workstations and portable computers) attach to 
a network. The current implementation of DHCP is based on theJ OIN 
product by Competitive Automation. 
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DMS 

Dataless Management Services. A service where a server maintains the root, 
/usr, and /var file systems for client computer systems connected to the 
server by a local area network (LAN). 


DMS area 


A reserved disk area physically connected toa DMS server, which contains 
multiple copies of the root area, one for each DMS client. 


DMS client 

A computer system whose system disk area is physically connected toa DMS 
server rather than to the client itself, and is accessed across the network 

by the client. 


DMS client area 

A DMS client area resides in each DMS area and is called /clients. 
Multiple copies of the root area residein the client area, each tailored from 
the appropriate generic root for an individual client. 


DMS environment 

A portion of a DMS area, containing software to support one or more 
clients. A DMS environment contains one or more DMS root areas. DMS 
environments are located in /var/adm/dms. 


DMS root area 

One root area is required for each client that is to be supported in the DMS 
environment. DMS root areas are located in /var/adm/dms/dmsN. alpha. 
Each root area contains a generic root directory and a shared /usr file 
system. 


DMS server 

A computer system that maintains the root, /usr, and /var file systems 
for DMS client systems. The DMS servers can contain multiple DMS 
environments to which clients are added. DMS clients are booted over a 
local area network (LAN). Swapping and dumping is not supported over the 
network and must be done on the clients’ local disks. 


dmu 

Dataless management utility, located at /usr/sbin/dmu. A text-based 
interface used to manage the sharing of installed operating software 
between DMS servers and clients. The dmu utility allows users to install, 
configure, show, and delete DMS environments and add, list, modify, and 
remove DMS clients. 


Dynamic Host Configuration Protocol 
See DHCP 
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generic root 

In DMS, a portion of the DMS environment that contains system software in 
a generic form, ready to be copied for tailoring to fit an individual client’s 
requirements. 


H 
hardware product 
A hardware product includes kernel modules to support hardware devices. 
A hardware product kit, such as a device driver, can be installed during 
the initial installation. 
With bootlinking, a method to include kernel modules during the boot 
process, the device driver can be loaded and the device used during the 
device installation process. 
See also NHD 

K 
kit 
A kit is a collection of files and directories that represent one or more 
layered products. It is the standard mechanism by which layered product 
modifications are delivered and maintained on the operating system. 
See also layered product 

L 
layered product 
A layered product is an optional software product designed to be installed as 
an added feature of the operating system. 

M 


member-specific file 
A file used by a specific cluster member. The contents of a member-specific 
file differ for each cluster member, and each member has its own copy of a 
member-specific file. 


See also cluster, cluster member, shared file 
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Network File System 
See NFS 


new hardware delivery 
See NHD 


NFS 
Network File System, an open operating system that allows all network 
users to access shared files stored on computers of different types. Users 


can manipulate shared files as if they were stored locally on the user’s own 
hard disk. 


NHD 

New hardware distribution (NHD) provides delivery of support for new 
hardware without providing a new release of the operating system, and can 
be offered on a regular basis. The kit is usually provided on CD-ROM, and 
includes installation and testing instructions. 


See also hardware product 


NIS 

Network Information Service. A distributed data lookup service for sharing 
information on a local area network (LAN). NIS allows you to coordinate 
the distribution of database information throughout your networked 
environment. 


new file 


In DMS, refers to files that are exactly as supplied in the software 
distribution kit and have not been customized. These files are used by the 
Update Installation process and allow the files to be delivered onto the 
system without overwriting the existing, and possibly customized version of 
the file. New files have a .new. prefix, and should never be modified. 


See also prototype file 


private area 


In DMS, a portion of the DMS area that is reserved for the exclusive use of a 
single client. The private area contains the client’s custom-tailored copy of 
certain operating system software files, including the kernal. 


product environment 


In RIS, a portion of the RIS area containing a set of software kits that are 
intended for installation on a particular client type, such as RISC processors. 
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product kit 
See kit 


profile set 

A profile set is a subdirectory of the /var/adm/ris/clients/sets 
directory on a RIS server. It contains configuration description files (CDFs) 
and user-supplied files that can be invoked during a Full Installation and 
used for Installation Cloning. When you register a RIS client for a RIS area, 
you can specify a profile set that contains CDFs and user-supplied files that 
you want to execute when you install software from the RIS area. 


See also CDF 


prototype file 

In DMS, refers to files that can be modified by the server’s system 
administrator so that they can be customized for a particular client site, 
such as /etc/hosts entries. Prototype files are prefixed with .proto.. 
and can be customized before the DMS environment is configured. 


See also new file 


Remote Installation Services 
See RIS 


RIS 

Remote Installation Services. A remote software distribution method where 
a server is set up to allow installation of software products over a local area 
network (LAN). RIS clients are registered on the RIS server to allow them 
access to specific software products. Using a RIS server makes installation 
of layered products faster and easier for all the clients on the network. 


RIS area 


A reserved disk area physically connected to a RIS server, containing one 
or more product environments. These contain software kits that can be 
installed on registered clients. Kits are organized so that a software product 
can supply several different versions for multiple hardware platforms. 


RIS client 


A computer system that has permission to install software across the 
network by accessing kits stored in the server’s RIS area. 


RIS server 


A computer system that serves other computers by providing operating 
system software for them to install; the software is stored on disks belonging 
to the server and is accessed across the network by the clients. 
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ris 

Remote Installation Services utility, located at /usr/sbin/ris. A 
text-based interface used to set up the RIS server and maintain RIS areas, 
the software products within the RIS areas, and RIS client registrations. 


server 


A computer system that serves one or more other computers, called clients, 
by providing resources to them. 


See also client 


shared file 
A file used by all members of a cluster. Thereis only one copy of a shared file. 


See also cluster, cluster member, menber-specific file 


software kit 
See kit 


subset 

The smallest installable software kit module that is compatible with the 
operating system's set 1d software installation utility. It contains files of 
any type, usually related in some way. 


TFTP 

Trivial File Transfer Protocol. TFTP is used during the RIS startup 
procedure to transfer the network kernel and supporting files from the RIS 
server tothe RIS client. For more information on TFTP, refer tothe t£tp(1) 
and tftpd(8) reference pages. 


user-supplied file 

User-supplied files are a way to extend and customize the installation 
process, and can contain scripts, executables, or programs. The Full 
Installation and Update Installation processes execute user-supplied files 
at predetermined points during the installation. 


User-installed files may include some or all of the preinstall, 
update preinstall, postload, update _postload, and postreboot 
files. 
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a DMS software environment, 12-7 
a RIS client, 6-9 

RIS product list, 6-12 


determining 


software subset size, 10-7 


DHCP, 5-1 
disk partitions 


allocating for DMS, 10-3 
on DMS server, 10-2 


disk space 


allocating for DMS, 10-3 

for DMS client area, 10-6 

overhead for DMS administration, 
10-5 

planning for DMS, 10-4, 10-5 

planning for RIS, 3-3 

showing use of, 12-14 


displaying 


disk usage, 12-14 


distribution device 


description of, 1-2 


distribution media, 4-1, 11-2 


(See also CD-ROM ) 


DMS, 1-1, 9-1 


adding a dient, 12-2 
booting a dient, 12-6 
C2 security, 10-9 
dient 
troubleshooting, 13-1 
client area, 9-5 
client registration, 10-7 
client system disk space, 10-4 
configuring environments, 11-11 
controlling growth of root area, 
12-14 
definition of, 9-1 
deleting an environment, 12-7 
disk space for environments, 10-4 
environment, 9-3 
files in /usr area, 9-4 


installing operating system on adding software to existing, 11-6 


server, 10-7 modifying for dient, 12-10 

installing required software naming conventions for, 11-5 
subsets, 10-7 DMS IP address 

installing software in new modifying for dient, 12-10 
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planning swap space, 10-8 setting up a client on, 3-4 


; Ethernet address 
t of kernel builds for, 10-6 ‘ 
ec a aia specifying for DMS client, 12-5 
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10-7 
software in existing DMS 
environment, 11-6 
software in new DMS environment, 
11-2 
internet address 
(SeelP address ) 
Internet address 
(SeelP address ) 
Internet Boot Protocol 
(SeeBOOTP ) 
internet daemon, 5-2 
IP address 


registering, 6-2 
registering for DMS client, 10-8 


J 


joind, 5-2 
joind daemon, 5-1, 8-6 
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management tasks, 12-15 mandatory subsets, 10-5 
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How to Order Tru64 UNIX Documentation 


To order Tru64 UNIX documentation in the United States and Canada, call 
800-344-4825. |n other countries, contact your local Compaq subsidiary. 


If you have access to Compaq’s intranet, you can place an order at the following 
Web site: 


http://asmorder.ngo.dec.com/ 


If you need help deciding which documentation best meets your needs, see the Tru64 
UNIX Documentation Overview, which describes the structure and organization of 
the Tru64 UNIX documentation and provides brief overviews of each document. 


The following table provides the order numbers for the Tru64 UNIX operating system 
documentation kits. For additional information about ordering this and related 
documentation, see the Documentation Overview or contact Compaq. 


Name Order Number 
Tru64 UNIX Documentation CD-ROM QA-6ADAA-G8 
Tru64 UNIX Documentation Kit QA-6ADAA-GZ 
End User Documentation Kit QA-6ADAB-GZ 
Startup Documentation Kit QA-6ADAC-GZ 
General User Documentation Kit QA-6ADAD-GZ 
System and Network Management Documentation Kit QA-6ADAE-GZ 
Developer’s Documentation Kit QA-6ADAF -GZ 
Reference Pages Documentation Kit QA-6ADAG-GZ 


TruCluster Server Documentation Kit QA-6BRAA-GZ 
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